* SNAT/Masquerade binding ports generate conflicts
@ 2005-12-07 15:28 Olivier GRALL
0 siblings, 0 replies; 2+ messages in thread
From: Olivier GRALL @ 2005-12-07 15:28 UTC (permalink / raw)
To: iptables
Hi,
I have a problem using iptables as a NAT box. I'm testing a p2p VoIP
system trying to establish UDP channels using something like STUN.
------------ snat ------------
------------
| A |-----| X |-----<-->------ | Server S
|---<----->-----| B |
------------(p1) \(P1) ------------
/ (P2) ------------
\------<----->-------<---->-------/
X is iptables with a MASQUERADE (or SNAT) rule
1- A sends a packet to S from port p1
2- X opens port P1 (should be equal to p1)
3- S answers to A with a message containing UDP port of B
4- B knows port P1 of X thanks to S too
=> Sometimes A sends the first packets of the communication to B through
X, then B can send packets to A too. Otherwise B sends the first packets
and X seems to drop them (we can see icmp). Then A sends UDP packets to
B and at this time iptables opens a new port 1024 for instance different
from P1.
It is like the uplet
[(src=(@A,p1),dst=(@B,P2)),(src=(@X,P1),dst=(@B,P2))] wasn't available
anymore and so iptables changes P1 to P1'. Doing this, only one part of
the uplet changes. I thought that conntrack forces the fact that for
(@A,p1),(@B,P2) there is only a unique couple on the other side (= at
the end of iptables treatments).
I used iptables 1.2.7a for that test. Anyone can tell me if a recent
version can solve this problem ?
Thanks.
Olivier GRALL.
^ permalink raw reply [flat|nested] 2+ messages in thread
* SNAT/Masquerade binding ports generate conflicts
@ 2005-12-08 14:50 Olivier GRALL
0 siblings, 0 replies; 2+ messages in thread
From: Olivier GRALL @ 2005-12-08 14:50 UTC (permalink / raw)
To: netfilter-devel
Hi,
I have a problem using iptables as a NAT box. I'm testing a p2p VoIP
system trying to establish UDP channels using something like STUN.
------- snat ------------ -----
| A |-----| X |-----<-->-----| Server S |---<----->-----| B |
-------(p1) \(P1) ------------ /(P2) -----
\ /
\-----<----->-----<---->------/
X is iptables with a MASQUERADE (or SNAT) rule
1- A sends a packet to S from port p1
2- X opens port P1 (should be equal to p1)
3- S answers to A with a message containing UDP port of B
4- B knows port P1 of X thanks to S too
=> Sometimes A sends the first packets of the communication to B through
X, then B can send packets to A too. Otherwise B sends the first packets
and X seems to drop them (we can see icmp). Then A sends UDP packets to
B and at this time iptables opens a new port 1024 for instance different
from P1.
It is like the uplet
[(src=(@A,p1),dst=(@B,P2)),(src=(@X,P1),dst=(@B,P2))] wasn't available
anymore and so iptables changes P1 to P1'. Doing this, only one part of
the uplet changes. I thought that conntrack forces the fact that for
(@A,p1),(@B,P2) there is only a unique couple on the other side (= at
the end of iptables treatments).
I used iptables 1.2.7a for that test. Anyone can tell me if a recent
version can solve this problem ?
Otherwise, is it possible to update the first conntrack record instead
of creating a new one (with port P1') ?
Thanks.
Olivier GRALL.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-12-08 14:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-08 14:50 SNAT/Masquerade binding ports generate conflicts Olivier GRALL
-- strict thread matches above, loose matches on Subject: below --
2005-12-07 15:28 Olivier GRALL
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.