FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
155 views 1 comments
by anonymous

Greetings... 

Definitely having some odd routing issues between our Sonicwall and the RUT9XX. Here is the current configuration:

Both the Sonicwall and the RUT9XX show that there is an IPSec tunnel. 

Our local networks behind the Sonicwall:  10.100.1.0/24 and 10.200.0.0/21

Our remote networks behind the RUT9XX:  10.200.103.0/24

The RUT9XX can ping anything behind the Sonicwall.

Devices behind the Sonicwall and the Sonicwall can ONLY ping the RUT9XX, but none of the devices behind the RUT9XX. The Sonicwall shows the traffic going to the IPSEC tunnel (consumed), but nothing on the RUT9XX. 

"ipsec status" gives me this... (Of course with identifiers removed... LOL)

AKPMFW-AKPMFW_c[1]: ESTABLISHED 30 minutes ago, XXX.XXX.XXX.XXX...XXX.XXX.XXX.XXX

AKPMFW-AKPMFW_c{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: XXXXXXXXXXXXXXXXX

AKPMFW-AKPMFW_c{1}:   10.200.103.0/24 === 10.200.0.0/21

AKPMFW-AKPMFW_c_1{2}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: XXXXXXXXXXXXXXXXX

AKPMFW-AKPMFW_c_1{2}:   10.200.103.0/24 === 10.100.1.0/24

It feels like there needs to be a policy or a route the allows VPN -> LAN, but I'm not sure where I would need to configure that.
Anybody have any ideas on how to proceed?

1 Answer

0 votes
by anonymous

Hello,

Please refer to the instructions on how to configure Teltonika devices with Sonicwall via IPsec provided in the following link: https://kaunas.teltonika.lt:444/f/6d6b4731ea324fc881b9/?dl=1.

Best regards,

Žygimantas

by anonymous

Ž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