HiHo all! I have viewed a strange conntrack behaviour. Sorry if this mail will be long, but it seems to be a quite complicated szenario, nevertheless it happens and is bugging me. ======================= Short questions for the impatient: - Why is netfilter using a port for NATing, even though the very same port is reserved by the router device though a listening socket, (but "free" from view of conntrack table.) - I need a way to reserve a certain touple in the conntrack table. Or - prevent a fixed touple from being used. (I know, it sounds strange but i need it :) ======================== Short description: I have three machines: A = a router 10.20.10.193 which is natting machine B B = 172.30.193.100 being behind A C = 10.20.0.95 a server In the conntrack i have an entry with: udp 17 0 src=172.30.193.100 dst=10.20.0.95 sport=5060 dport=5060 src=10.20.0.95 dst=10.20.10.193 sport=5060 dport=5060 [ASSURED] .. even though A itself is listening on port 5060. ....... sport=5060 dport=5060 [ASSURED] ^^^^ I don't like this, should not be 5060 ====================================== Longer Scenario description: No let me explain why this is a Problem. The setup is the same as above, i just repeat the ips for easier understanding. I have a service running on a linux router A, the same service is running behind this router on a another machine B. The service is SIP connecting to a fixed sip-server C. SIP uses fixed ports for src and dst. It can be any port, but after signalling it must be fixed and default is 5060. This is very important, because this will now lead to two touples with A:5060 C:5060 for the router and B:5060 C:5060 for the machine behind the router A does also NAT machine B Now when the router connects to the sip-server i get a correct entry in connection tracking. A= 10.20.10.193 C= 10.20.0.97 udp 17 19 src=10.20.10.193 dst=10.20.0.97 sport=5060 dport=5060 src=10.20.0.97 dst=10.20.10.193 sport=5060 dport=5060 [ASSURED] use= So far ok. Note that the service has opened a Socket for 5060 on A, it is listening on 5060. Now after this entry expires, let B connect to C B=172.30.193.100 which is a subnet to router A udp 17 0 src=172.30.193.100 dst=10.20.0.95 sport=5060 dport=5060 src=10.20.0.95 dst=10.20.10.193 sport=5060 dport=5060 [ASSURED] use=1 ======================== Well. I know this behaviour is probably ok, as the old entry is expired from conntrack table. So technically it looks ok for now. BUT I don't like that the natted dport 5060 is used. ....5060 dport=5060 [ASSURED] ...... ^^^^^-should NOT be 5060. Yes i know it was free from conntrack view. But A is still listening on port 5060 (open socket). Because now we run into a problem. The first connect has told the SIP server, which ports the router uses (5060). The problem is that once we are registered the sip-server can also initiate a connection which he does for an incoming call. So now the sip-server sends a packet from C:5060 to A:5060 telling A that he has a call, which now will be forwarded due to the later conntrack entry to the machine B. To make things even worse. B (being intelligent) has detected via stun that it is behind nat, so it constantly refreshes it's connection by sending keep-alive packets to C. So the second conntrack-entry will never expire. Which itself is also correct. The only problem i see is that the natted DPORT in the touple is 5060 instead of anything else. If it would have been anything but 5060, both machines and both services could coexist fine. ============== So here are the questions: - Anyone out there agree with me that this behaviour is not 100% ok. - How can i "reserve" or fix the first conntrack entry I mean if it wouldn't expire i wouldn't have a problem. And i dont want the server to send a packet every few seconds just to keep it's OWN conntrack entry valid. - Or How can i prevent that NATed entry from being created. I can circumvent the problem with: iptables -I POSTROUTING -p upd -s ! A --sport 5060 -j MASQUERADE --to-ports 32017-32042(anything but 5060) actually a ....MASQUERADE --to-ports ! 5060 would do the trick, but is not allowed. For all the quick schooters out there: Yes I know there are different ways of circumventing the problem - configure B to not use 5060 - block lan-sided 5060 - using fixed Masquerade as described above. And yes i know it is usually not a problem, that's why other protocols use high-ports. It's a problem of stupid SIP that it is created like this. Yet this doesn't help me at all. I have reasons to use it exactly as discribed above, the easiest but most important: B may not be under my control. So i definitly don't want B to steal my service, yet i also don't want to deny B's service. phew, that's it. I hope at least one has read this far. So my best wishes for you and thanxs :) ciao markus ------------------------------------------------------ markus schaefer --- software engineer epygi labs de gmbh herrenstrasse 23 d-76133 karlsruhe, germany tel: +49 (721) 205 96 30 -- fax: +49 (721) 205 96 59 http://www.epygi.de