Žygimantas...
Thank you for your answer; however, a couple things to note.
1. BOTH UIs have been drastically updated since this document was made. In the case of Sonicwall, you might be 3 major versions of the UI behind. In the case of Teltonika's at least 1 if not 2 versions of the UI behind. (I'm currently running 7.01.4)
2. After comparing notes to the document, I have it set-up pretty close to that way. (IP's changed for our environment.)
So the issue isn't the IPSEC VPN, that's up and running. It's ALL about routing on the Teltonika.
T-network --> Teltonika --> Sonicwall --> S-network
(Appears to work from the Teltonika all the way into the S-network. None of the devices on the T-network are accessible to see if they can talk to the S-network. (Those devices are all web-enabled.))
S-network --> Sonicwall --> Teltonika --> T-network
(Appears to work from the S-network to the Teltonika works, but the S-Network and the Sonicwall can't see anything on the T-network. The Teltonika can do anything on the T-Network.)
Doing a ping from my local PC: 10.100.1.58 to a radio transmitter (10.200.103.50) and a TCPDUMP on the Teltonika. I get this:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
08:55:41.468784 IP 10.100.1.58 > 10.200.103.50: ICMP echo request, id 1, seq 6601, length 40
08:55:46.610099 ARP, Request who-has 10.200.103.50 tell Alaska_Public_1.lan, length 28
08:55:46.610552 ARP, Reply 10.200.103.50 is-at 00:1f:7b:0a:42:68 (oui Unknown), length 46
08:55:46.632208 IP 10.100.1.58 > 10.200.103.50: ICMP echo request, id 1, seq 6602, length 40
08:55:51.489813 IP 10.100.1.58 > 10.200.103.50: ICMP echo request, id 1, seq 6603, length 40
08:55:56.551439 IP 10.100.1.58 > 10.200.103.50: ICMP echo request, id 1, seq 6604, length 40
If you notice. There is NOTHING coming back to reply back to the ICMP. If I ping from the Teltonika which does get a response.I get this:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
08:27:15.387931 IP Alaska_Public_1.lan > 10.200.103.50: ICMP echo request, id 25303, seq 0, length 64
08:27:15.388239 IP 10.200.103.50 > Alaska_Public_1.lan: ICMP echo reply, id 25303, seq 0, length 64
08:27:16.394595 IP Alaska_Public_1.lan > 10.200.103.50: ICMP echo request, id 25303, seq 1, length 64
08:27:16.394862 IP 10.200.103.50 > Alaska_Public_1.lan: ICMP echo reply, id 25303, seq 1, length 64
08:27:17.394982 IP Alaska_Public_1.lan > 10.200.103.50: ICMP echo request, id 25303, seq 2, length 64
08:27:17.395345 IP 10.200.103.50 > Alaska_Public_1.lan: ICMP echo reply, id 25303, seq 2, length 64
08:27:20.395785 ARP, Request who-has Alaska_Public_1.lan tell 10.200.103.50, length 46
08:27:20.395930 ARP, Reply Alaska_Public_1.lan is-at 00:1e:42:2e:08:8b (oui Unknown), length 28
08:27:20.626099 ARP, Request who-has 10.200.103.50 tell Alaska_Public_1.lan, length 28
08:27:20.626525 ARP, Reply 10.200.103.50 is-at 00:1f:7b:0a:42:68 (oui Unknown), length 46
It looks like VPN Subnets don't have access to route to the Alaska_Public_1.lan.
Anybody else have any ideas that might work?
Thanks