[Openswan Users] 26Sec to OpenSwan-1.0.3 dual-subnet routing problem

[Charles Jones]

Back in the day, Herbert Xu said:
> Please cc me when replying if you want me to read your message.
> 
> Charles Jones <linkst8.ipsec at scriptable.net> wrote:
> > Back in the day, Herbert Xu said:
> >> linkst8.ipsec at scriptable.net wrote:
> >> >
> >> >    /usr/sbin/iptables -t nat -I POSTROUTING -o $EINT -d ! $gw -j MASQUERADE
> >> 
> >> If this is the script on the 26sec machine then please try removing
> >> the MASQUERADE rule.  Applying MASQUERADE rules on a 26sec stack
> >> to IPsec packets results in unexpected behaviour like this.
> > 
> > Thanks for the suggestion, but the "!" in the above iptables statement
> > is there to ensure that masquerading is not performed on the traffic
> > from the listed ipsec gateway.  Or am I mis-interpreting your advice?
> 
> Yes you're right.  However, NATing with the new stack is so broken
> that this may not be doing the right thing depending on whether it's
> matchiing against the pre or post-encap packet.
> 
> Anyway, please check the following things:
> 
> 1. Make sure that rpfilter is turned off on $EINT.
> 2. Make sure that your packet is not disappearing due to NATing
> by doing 'grep 10.10.10 /proc/net/ip_conntrack'.
> 3. Make sure that the decrypted packet is arriving in the FORWARD table
> by LOGging it.
> 4. Make sure that it is being accepted there.
> 
> Cheers,

That brings up a question.  And I'm hoping that you didn't just answer it
in that reply.  (crosses fingers)

What is the path taken by an IPsec packet through the kernel with and
without NAT?  I've found some ordering problems in my firewall script's
rule applications, and have become confused at which point the packets
are considered going through the various targets. (INPUT, OUTPUT,
FORWARD, nat)  I've been using your suggestion, and having my packets
ULOG'd as they match.  This has been a great troubleshooting tool in my
particular situation, you have my thanks for that.  However, if I could
get a picture of what the path of a NAT'ed ipsec packet was, I could
most likely put this issue to bed.

Thanks,

-- 
For a copy of my public key, send an email to gpgkeys _at_ scriptable _dot_ net with "send pgp key" in the subject.

Linux renders ships. Windows is rendering ships useless...