[Openswan Users] openswan + l2tpd + iptables problem

[mechanix at debian.org]

On Tue, Oct 17, 2006 at 03:56:47PM +0200, Paul Wouters wrote:
> On Tue, 17 Oct 2006, mechanix at debian.org wrote:
> 
> > I've taken care of the MTU issues now; and SA negotiation succeeds.
> >
> > I'm still stuck at l2tp being blocked by the iptables rules however.
> > I have these rules present:
> >
> > ...
> > iptables -t mangle -A PREROUTING -p ESP -j MARK --set-mark 50
> > iptables -t mangle -A PREROUTING -p IPENCAP -j MARK --set-mark 50
> > iptables -A INPUT -m mark --mark 50 -p udp --dport 1701 -j ACCEPT
> > ...
> 
> IPIP (ipencap) is not used by IPsec / Openswan). perhaps you are confused
> with IPsec encapsulated in udp port 4500?

No, I know NATted IPsec works by encapsulation over udp 4500.

Hmm, I can't seem to find blocked ipencap traffic in the firewall logs.
Ok, I've removed the rule to allow ipencap and restarted openswan on the
SG gateway to check. Seems to work. However, I am now getting these now:

Oct 17 22:31:13 scotos kernel: IN=eth1 OUT= MAC=[...] SRC=BE.IP.ADDR.ESS DST=SG.IP.ADDR.ESS LEN=505 TOS=0x00 PREC=0x00 TTL=99 ID=0 DF PROTO=4

These are between the two VPN gateways, incidentally, so I would have
guessed that it would be from the net2net tunnel.
Unfortunately there's no-one available ATM to check how this affects
roadwarrior attempts. I'll check later, possibly tomorrow.

I'm still certain that letting ipencap through did have effect on the
Singaporean VPN gateway back when I added it - just don't remember what
it did.

> > These are all at the very beginning of their respective chains.
> >
> > Initially I had only the -p ESP mangle rule; but I remembered that I had
> > IPENCAP traffic hitting the firewall last week before I got SA to work
> > which I had to unblock back then; so I added a mangle rule for it too.
> > Also, I tried -t mangle -A INPUT as well but with no success either.
> >
> > The hosts that have been trying to connect were behing NAT; not sure if
> > that is part of the problem, but even then we need it to work for these
> > anyway.
> 
> You should allow udp port 4500.

It already is.


Regards,

Filip

-- 
http://www.sysfs.be/