[Openswan Users] Old user having troubles with new techniques

[Larry Brown]

On Wed, 2010-06-30 at 09:54 -0700, Bob Miller wrote:
> Hi Larry,
> I can't give you a specific answer, but I can say my personal rules of
> thumb in troubleshooting these problems.
> First, once the tunnel comes up, I have found that in general you don't
> need to mess with your openswan config anymore.  

This is how I've been looking at it where the tunnel is concerned but
some comments I've read state the routing is controlled by the networks
in the ipsec.conf file and that if it is right it "just works".  So I
just sent the tunnel output just in case my ignoring it thinking it is
the part that is working as expected and doesn't need fixing was wrong.

> As a rule, at least for
> me, the only thing you can add is features to tunnel, such as being able
> to ping the gateway on the other end.
> Once I see "SA established", the next place I look is the l2tp log.  If
> I find error in there, I fix it.  I dont' recall seeing that you were
> using l2tp, so probably doesn't apply in your case.

Correct, I'm not using PPP nor L2TP.

> Since you are using netkey, you will need to mark your packets with
> iptables as they are accepted, then the remaining iptables rules will be
> used to match on those marks.  This took me a long while to wrap my head
> around when I first started playing with it, but in the end it works for
> me every time now.

I was thinking without an ipsec0 that some kind of marking would be
necessary but the howto didn't mention it at all.  I followed the link
below and used:

iptables -t filter -A INPUT -p 17 --dport 500 -j ACCEPT
iptables -t filter -A INPUT -p 50 -j ACCEPT
iptables -t mangle -A PREROUTING -p 17 --dport 500 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p 50 -j MARK --set-mark 1
iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT
iptables -t filter -A FORWARD -m mark --mark 1 -j ACCEPT
iptables -t filter -A OUTPUT -j ACCEPT
iptables -t filter -A FORWARD -s 172.16.0.0/24 -j ACCEPT
iptables -A OUTPUT -m policy --pol ipsec --dir out -p 4 -j ACCEPT

I brought both ipsec services down and back up and recreated the tunnel.
No good.  Packets on the office gateway still show up after the
un-encryption as ICMP packets with source of the roadwarrior's
192.168.2.1 address and destination of the Office server's 172.16.0.4
address on the public interface and no packets being sent over the LAN
interface where 172.16.0.4 resides.

> This link is the one from Peter McGill that finally helped me piece it
> all together, hopefully it gives you example enough to work from:
> http://archives.free.net.ph/message/20080110.130102.6808daae.ja.html
> good luck, persistence is key...
> 
> 

I'm trying to be persistent but it is driving me nuts after 4 days of banging my head :)