[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ipsec
Subject:    RE: [Users] Netfilter and Freeswan (Addendum)
From:       "Joe Patterson" <jpatterson () asgardgroup ! com>
Date:       2001-10-30 21:16:08
[Download RAW message or body]

I've had some interesting fun with iptables/netfilter.  I have noticed some
interesting things, if you're doing statefull connection tracking.

First, note that for isakmp packets, the sport==500==dport.  So you come up
with some interesting things.  left sends an isakmp packet to right.
Neftilter sees this packet, and opens a hole for the return traffic,
left/17/500<->right/17/500.  The packet gets to right, which doesn't have a
connection in its table for it, so drops it.  Then left sends its isakmp
packet, which its firewall sees and opens up a hole for return traffic,
right/17/500<->left/17/500.  And suddenly, everything (isakmp-wise) starts
working.  Once the tunnels have been negotiated, traffic starts flowing.
Since ESP and AH don't really have "ports", only SPI's (and unless you live
on the bleeding edge and specifically tell it to, netfilter has no concept
of what an SPI is), but netfilter still tries to track the connection as
best it can, with a sourceIP/proto<->destIP/proto mentality.  You get into
an interesting state, where things will sometimes work, and sometimes not.
Say, for instance, I ping something on the other side.  KLIPS encapsulates
this into ipsec, and ships it out the tunnel.  Netfilter sees the traffic
going out, and puts something in its connection tracking table, like
left/50<->right/50.  That ESP packet gets to the other side, and is dropped.
I leave that ping going.  Now I ping from the other side.  It sees the
traffic going out, and adds to its conntrack table something like
right/50<->left/50.  That ping works, and suddenly my first ping starts
working too!  All traffic can flow, as long as some traffic is flowing from
both sides.  But if at any time, traffic stops long enough for the
connection tracking to time out, you're back at square one again.

In the end, the correct solution is to explicitly allow protocols 50 and/or
51, and udp port 500 inbound.  But it can be really frustrating if you don't
know what's happening.

-Joe

-----Original Message-----
From: users-admin@lists.freeswan.org
[mailto:users-admin@lists.freeswan.org]On Behalf Of Hutch Hicken
Sent: Tuesday, October 30, 2001 3:06 PM
To: users@lists.freeswan.org
Subject: [Users] Netfilter and Freeswan (Addendum)


Hi All,

My previous message probably only described half of the problem.  You
see from the other side of the tunnel I am able to start up the ipsec
connection (at least ostensibly) but the two outside subnets still can't
talk.

Any ideas?  Should I post a barf?

--hutch


_______________________________________________
Users mailing list
Users@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

[prev in list] [next in list] [prev in thread] [next in thread]