On Sunday 14 March 2004 12:55 am, Carsten Maass wrote:
> Antony Stone wrote:
> > On Saturday 13 March 2004 10:16 pm, Carsten Maass wrote:
> > >
> > > $IPTABLES -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source
> > > $INET_IP
> > >
> > > It seems to do some kind of NATing to all traffic leaving the gateway.
> >
> > Er, why shouldn't it do this? The rule says "for any packet leaving
> > $INET_IFACE, change the Source Address so that it is $INET_IP".
>
> Not all traffic should be SNATed, only traffic leaving via $INET_IFACE.
> Traffic leaving via $LAN_IFACE should not be altered, which the above
> rule nevertheless did.
Oh, sorry - when you said "leaving the gateway", I kind of assumed you meant
"going to the outside world" - my mistake.
> > So the new rule will not SNAT anything which already has a source address
> > other than 192.168.3.0/24 (such as, for example, $INET_IP). It seems to
> > me that this is probably necessary because of the way your IPsec packets
> > are now going twice through the same interface (in the old 2.4 FreeS/WAN
> > implementation, they would go once through eth0, and once through ipsec0,
> > but I believe this is no longer the case?)
>
> Yes, they are going twice through $INET_IFACE, but the alteration occurs
> when leaving through $LAN_IFACE, which should not be matched as
> SNAT-target by the original rule. And in fact occurs no full SNAT but a
> change of the source port.
I wonder if this is a problem the reverse-nat code is having, trying to keep
track of packets which are going through the same interface twice? When a
packet gets natted, netfilter keeps a record of the original IP+port and the
substituted IP+port, so that when a reply packet comes back the reverse
operation can be automagically applied. The code does not change the port
number unless something is already bound to that port on the natting machine,
in which case the port number will be changed.
I wonder if the first time the packet goes through, the IP is changed but not
the port number, however the second time, there's already an entry in the nat
table, so the port number does get changed, and then when the response is
seen, the code incorrectly applies the reverse nat to the IP+port
combination?
Just a theory, but maybe it'll point somebody in a helpful direction when
investigating this further? (Maybe even me, when I get round to dealing
with 2.6 and inbuilt IPsec....)
> Maybe at least we both agree that the above behavior is not *intended*
> by the applied rule? :)
Yes :)
Antony.
--
Anyone that's normal doesn't really achieve much.
- Mark Blair, Australian rocket engineer
Please reply to the list;
please don't CC me.
