WIKIABOUT

FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

Most popular tags

rut955 rut240 rut950 rutx11 rms vpn to openvpn wifi not sms trb140 firmware connection - ipsec on rutx12 rutx09 modbus
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.

UDP Session causing forwarded packets to change ports when replying.

0 votes
412 views 2 comments
by anonymous

RUT951, FW RUT9M_R_00.07.03.3

Hi - I have one of the RUT951, and I'm port forwarding from a VPN tunnel to an internal device. All looks good, traffic flows in, and Internal device can communicate out. All happy, so Forwarding rules are OK.

Where I'm stuck is the first 60 seconds of a new session. Let me explain.

note, all this is real time UDP - think a VoIP phone, however it's not SIP, it's just UDP traffic.

When a session is opened from inside the LAN (Host B), out to the VPN, port 5000 is opened. when the web endpoint (host A) responds, it replies on 5000. both ends can communicate in real time no problem.

Host A      ------ ens   Router   tun  ------ Host B
                                                Start Packet:5000
                                  Packet:5000
                       Route Packet
             Packet:5000
Packet:5000
...
Reply Packet:5000
             Packet:5000
                       Route Packet
                                  Packet:5000
                                                Packet:5000
All looks normal, but if it's the other way around..

Start Packet:5000
             Packet:5000
                       Route Packet
                                  Packet:5000
                                                Packet:5000
                                                ...
                                                Reply Packet:5000
                                  Packet:5000
                       Route Packet
             Packet:1234
Fail Packet

When a session is opened from the Web via the VPN, port 5000 is forwarded to the internal device. The internal device replies on 5000, but because the RUT951 remembers the inbound session on port 5000, it reforms the packet - sending via a random port to the web endpoint through the VPN tunnel. Because the port is mismatched, the web endpoint rejects the traffic.

after 60 seconds, the session closes, and we're back to either end able to reopen a session, and communicate again (in either of the two scenarios above).

tcpdump shows (yes, IP's have been replaced)

14:03:35.255453 ethertype IPv4, IP InternalIP.5000> webIP.5000: UDP, length 172           // initiate session from LAN > Web
14:03:35.255477 IP InternalIP.5000> webIP.5000: UDP, length 172                           // forward to internal Ethernet devices
14:03:35.255503 IP InternalIP.5000> webIP.5000: UDP, length 172                           // ..bridged interfaces, so duplicated
14:03:35.255644 IP VPNIP.5000 > webIP.5000: UDP, length 172                               // send to web via vpn interface

14:03:39.159725 IP webIP.5000 > VPNIP.5000: UDP, length 172           // reply from web
14:03:39.159871 IP webIP.5000 >InternalDeviceIP.5000: UDP, length 172                     // forward to internal Ethernet devices
14:03:39.159898 IP webIP.5000 >InternalDeviceIP.5000: UDP, length 172           // ..bridged interfaces, so duplicated

That all seems OK.

13:59:06.486520 IP webIP.5000 > VPNIP.5000: UDP, length 172                         // initiate session from web > LAN
13:59:06.486693 IP Teltonika-RUT951.com.5000 > InternalDeviceIP.5000: UDP, length 172    // forward to internal Ethernet devices
13:59:06.486721 IP Teltonika-RUT951.com.5000 > InternalDeviceIP.5000: UDP, length 172    // ..bridged interfaces, so duplicated

13:59:10.466055 ethertype IPv4, IP InternalIP.5000 > webIP.5000: UDP, length 172          // reply
13:59:10.466078 IP InternalDeviceIP.5000 > webIP.5000: UDP, length 172                  // forward to internal Ethernet devices
13:59:10.466103 IP InternalDeviceIP.5000 > webIP.5000: UDP, length 172                   // ..bridged interfaces, so duplicated
13:59:10.466301 IP VPNIP.1234 > webIP.5000: UDP, length 172                        // send to VPN on random port because 5000 is in use

NOW, this is much like SIP ALG - indeed, I've tried turning off the conntrack helpers, and disabling all of those, but to no avail.

If I could force the LAN side to open a session and keep it running, there would be no issue, but I can't guarantee that is always the case (and it definitely needs to be reliable).

Annoyingly, I had it behaving for a moment - all seemed fine, but then I got mixed up, and it's not working again, so it seems there is a solution - if I can find it.

And I've checked all on the VPN side - it sees one packet in, and forwards one packet straight through (to the correct destination). That side seems fine.

Kinda tearing out my hair here..

1 Answer

0 votes
by anonymous

Hello,

Have you tried to rewrite the source port via iptables/firewall? SNAT is also available via WebUI in Network -> Firewall -> NAT Rules. You can specify VPN firewall zone, source port, etc (unless you are using IPSec which does not have its own firewall zone).

Kind Regards,

Best answer
by anonymous
Yeah, I did try that.. although again, I had it working then it failed again.

Will give it a go again, although it didn't work when I tried that this morning.
by anonymous
Looks like SNAT matching LAN interface, IP + port, then outbound interface (VPN) + SNAT IP (VPN Interface) + Desired outbound port seems to be working. Thank you!

For the record (and those stumbling across that later) I'm not using IPSec - but OpenVPN. Seems to be working well for me now. Thanks @Andejj!

EDIT - it's close - but still seems to be playing up. Had it working for about 5min, but then it isn't again - so there is something funny happening in how the rule applies.