K
K
kruft2011-10-19 20:20:54
linux
kruft, 2011-10-19 20:20:54

SNAT to wrong source address of SIP udp packets after changing default route on router?

There is a router system (Debian current, 2.6.32-5-686) with two uplinks (both Ethernet, without ppp and pppoe) and another LAN interface, inside which there is a server with Asterisk pbx.
Of the uplinks, one is the main one, by default the default route leads to it in the main routing table. Also, source-routing is configured on the router for separate access via Linux Advanced Routing HowTo (so that response packets go to the same place where requests came from).
In this mode, everything works as it should.
In addition, self-made uplink health monitoring is configured (ping one external address every 10 seconds, if the address is unavailable through the default uplink, the current default route is deleted, ip route flush cache, all active tcp sessions are forced to break within 3 seconds by means of iptables and finally setting the default route to fallback uplink). At the same time, for everything except Asterisk, connections are quickly re-uplinked through a new uplink.
!!! udp sip packets from Asterisk (for registration on a higher sip proxy) also start to be sent to the new interface by default, according to the rules, BUT - SNAT works to the old source address (the interface address of the first uplink is set as outgoing). After that, respectively, nothing works, because. the first router of the provider blocks packets with a source IP address that does not belong to its subnets. This situation occurs before the reboot of our router. There, nat starts working again as it should, but until the default route is changed back to the default provider, after that SNAT of sip packets occurs by inertia to the address of the backup provider.
I don’t know exactly where to dig and what to look for, a request to Habrahumans to help as much as possible :-)

Answer the question

In order to leave comments, you need to log in

4 answer(s)
E
Eugene, 2014-06-01
@kruft

conntrack -F

@
@greynix, 2011-10-19
_

Since the SNAT rule is not shown, I can guess that adding to your “uplink health monitoring” rewriting the SNAT rule when the uplink falls, to exit through another interface can help.

P
paralon, 2011-10-20
@paralon

I think this is due to the fact that NAT works with the old, already formed NAT table. After rebooting the router, the table is reset to zero, re-formed - and everything starts working fine.
Exit - after switching to the reserve, reset the NAT table.
I don't know how to do it in linux, but I think it can be solved by restarting the iptables daemon.
The answer does not claim to be true, but still check. For example, look at the NAT table before the link falls, after the fall, and after the reboot.
Good luck! If you find a solution - unsubscribe somewhere ;)

@
@greynix, 2011-10-20
_

I see several options here:
1. If I understood correctly, then the problem is only with the asterisk, i.e. Do other applications send packets normally? Perhaps the problem is in the asterisk (there are subtle moments in the procedure for sending an invite in which the external ip address is indicated), but what does tcpdump say, is there something interesting there?
2. If you write only one SNAT rule when changing the default gateway, you will be able to see the packets actually sent fall into the wrong SNAT rule.
The problem is very interesting, if you want to write to me in PM or on jabber I will try to help.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question