[Openswan Users] pings not encrypting.
Bob Miller
bob at computerisms.ca
Tue Aug 25 23:10:57 EDT 2009
Hello,
I have come back to visit some of my favourite mysteries, this
particular one being an issue where I have not so far been able to get a
net-to-net configuration working side-by-side with a road warrior
configuration.
The particular firewalls involved are both untarnished installs of
current versions of debian. the left firewall was configured some
months ago for road warriors to log into a domain through an ipsec/l2tp
vpn, and to my knowledge, has been working fine since. The right
firewall was built yesterday, and I wish to add a net-to-net config
between the two.
Both firewalls run the debian ipmasq package, and all software is from
the debian testing repositories. I am using x509 certs generated from a
self-signed cert authority, and these certs have been working for the
road warriors.
topology as follows:
Left side:
192.168.150.0/24<=left-firewall=>216.126.98.194<=>216.126.98.193<=internet
right side:
internet=>207.189.252.13<=>207.189.252.14<=right-firewall=>192.168.25.0/24
road warriors:
internet=>?.?.?.?(dsl router)<=>10.250.10.0/24(ip pool used by
l2tpns)<=>local address
1. the problem:
Pings sent from either side of the net-to-net connection exit the
external interface bound for their non-routable destinations, not as
encrypted ESP packets. ie, ping -I 192.168.150.10 192.168.25.10 yields
on tcpdump IP 216.126.98.194 > 192.168.25.10, when it should be showing
an encapsulated packet.
2. Why I think it should work:
-ipsec verify checks out on both machines.
-ipsec auto --status contains these lines, and both sides concur that
the SA is established:
000 #4: "computerisms-ctfn":500 STATE_QUICK_R2 (IPsec SA established);
EVENT_SA_REPLACE in 27214s; newest IPSEC; eroute owner
000 #4: "computerisms-ctfn" esp.b9589aa at 216.126.98.194
esp.9270fcff at 207.189.252.14 tun.0 at 216.126.98.194 tun.0 at 207.189.252.14
000 #3: "computerisms-ctfn":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA
established); EVENT_SA_REPLACE in 2014s; newest ISAKMP; lastdpd=-1s(seq
in:0 out:0)
-ip route shows a route to the opposing subnet:
leftside:
216.126.98.192/30 dev eth2 proto kernel scope link src
216.126.98.194
10.250.10.0/24 dev tun0 scope link
192.168.150.0/24 dev eth1 proto kernel scope link src 192.168.150.1
192.168.25.0/24 via 216.126.98.193 dev eth2
default via 216.126.98.193 dev eth2
and right side:
207.189.252.12/30 dev eth0 proto kernel scope link src
207.189.252.14
192.168.150.0/24 via 207.189.252.13 dev eth0
192.168.25.0/24 dev eth1 proto kernel scope link src 192.168.25.1
default via 207.189.252.13 dev eth0
-I have added firewall rules:
left side:
iptables -I INPUT -m policy --dir in --pol ipsec -p udp -d
216.126.98.194 --dport 1701 -j ACCEPT
iptables -I INPUT -p udp -d 216.126.98.194 --dport 500 -j ACCEPT
iptables -I INPUT -p udp -d 216.126.98.194 --dport 4500 -j ACCEPT
iptables -I INPUT -p 50 -d 216.126.98.194 -j ACCEPT
iptables -I INPUT -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT
iptables -I INPUT -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT
iptables -I INPUT -s 192.168.150.0/24 -d 192.168.0.0/16 -j ACCEPT
iptables -I INPUT -s 192.168.0.0/16 -d 192.168.150.0/24 -j ACCEPT
iptables -I FORWARD -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.150.0/24 -d 192.168.0.0/16 -j ACCEPT
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.150.0/24 -j ACCEPT
iptables -I OUTPUT -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT
iptables -I OUTPUT -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT
iptables -I OUTPUT -s 192.168.150.0/24 -d 191.168.0.0/16 -j ACCEPT
iptables -I OUTPUT -s 192.168.0.0/16 -d 191.168.150.0/24 -j ACCEPT
right side:
iptables -I INPUT -p udp -d 207.189.252.14 --dport 500 -j ACCEPT
iptables -I INPUT -p udp -d 207.189.252.14 --dport 4500 -j ACCEPT
iptables -I INPUT -p 50 -d 207.189.252.14 -j ACCEPT
iptables -I INPUT -s 192.168.25.0/24 -d 192.168.150.0/24 -j ACCEPT
iptables -I INPUT -s 192.168.150.0/24 -d 192.168.25.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.25.0/24 -d 192.168.150.0/24 -j ACCEPT
iptables -I FORWARD -s 192.168.150.0/24 -d 192.168.25.0/24 -j ACCEPT
iptables -I OUTPUT -s 192.168.25.0/24 -d 191.168.150.0/24 -j ACCEPT
iptables -I OUTPUT -s 192.168.150.0/24 -d 191.168.25.0/24 -j ACCEPT
3. Things I have tried:
-ifconfig ethx mtu 1400 <= *I have found this to be necessary for just
about every openswan installation I have done.
-monkeying with various config options in ipmasq and ipsec.conf
--explicitly defining the opposing network as allowed using the
virtual_private setting.
--disabled nat on the right side (need it for the left)
--using explicitly defined /24 networks in the iptables rules on the
left instead of 192.168.0.0/16 (this is there because I want to add more
later)
--lots of other things as suggested by man page or google articles
-checked through a barf to look for problems/errors
-scoured for typos in config files
-enabled full pluto debugging and looked for errors/problems
-much googling
4. Points of interest:
-/etc/init.d/ipsec restart will always result in this error in syslog on
both computers, even though ipsec auto --status contradicts it (again,
on both computers):
Aug 25 13:14:03 fw-ctfn ipsec__plutorun: 104 "computerisms-ctfn" #1:
STATE_MAIN_I1: initiate
Aug 25 13:14:03 fw-ctfn ipsec__plutorun: ...could not start conn
"computerisms-ctfn"
-With some debugging turned on, this shows up after the SA is
established:
"computerisms-ctfn" #1: ignoring Delete SA payload: PROTO_IPSEC_ESP
SA(0xb599883d) not found (maybe expired)
--Andreas Steffen addresses this on a mailing list - looks to be a
harmless message.
-ipsec.conf:
left side:
version 2.0
config setup
interfaces="%defaultroute"
plutodebug=none
klipsdebug=none
virtual_private=%v4:192.168.0.0/16,%v4:10.0.0.0/8,%v4:172.16.0.0/12,%
v4:!192.168.150.0/24
nat_traversal=yes
conn %default
keyingtries=5
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem
auto=add
conn rw-l2tp-ctfn
left=216.126.98.194
leftnexthop=216.126.98.193
leftprotoport=17/%any
leftrsasigkey=%cert
right=%any
rightprotoport=17/%any
rightrsasigkey=%cert
pfs=no
conn rw-ctfn
left=216.126.98.194
leftnexthop=216.126.98.193
leftsubnet=192.168.150.0/24
leftrsasigkey=%cert
right=%any
rightrsasigkey=%cert
pfs=yes
rightsubnetwithin=192.168.0.0/16
conn computerisms-ctfn
left=216.126.98.194
leftnexthop=216.126.98.193
leftsubnet=192.168.150.0/24
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem
right=207.189.252.14
rightnexthop=207.189.252.13
rightsubnet=192.168.25.0/24
rightcert=/etc/ipsec.d/certs/gatelian.computerisms.ca.pem
auto=start
# rightid=@gatelian.computerisms.ca
# leftid=@fw-ctfn.ctfn.ca
include /etc/ipsec.d/examples/no_oe.conf
right side:
version 2.0
config setup
interfaces="%defaultroute"
plutodebug=all
klipsdebug=none
virtual_private=%v4:192.168.0.0/16,%v4:10.0.0.0/8,%v4:172.16.0.0/12,%
v4:!192.168.25.0/24
nat_traversal=yes
conn %default
keyingtries=5
auto=add
leftrsasigkey=%cert
rightrsasigkey=%cert
conn computerisms-ctfn
left=216.126.98.194
leftnexthop=216.126.98.193
leftsubnet=192.168.150.0/24
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem
right=207.189.252.14
rightnexthop=207.189.252.13
rightsubnet=192.168.25.0/24
rightcert=/etc/ipsec.d/certs/gatelian.computerisms.ca.pem
auto=start
# leftid=@fw-ctfn.ctfn.ca
# rightid=@gatelian.computerisms.ca
include /etc/ipsec.d/examples/no_oe.conf
6. conclusions/theories/comments
-Once upon a time I remember having a problem with the debian ipmasq
package because the internet interface was not eth0. Here, I note it is
eth2 on the left side, but since it was working for road warriors, I do
not see why it should be having this problem with a net-to-net config.
-I cannot find an error to fix, I cannot find a reason for this to not
be working. I have enabled full logging and not found a problem. All
aspects seem to be in order, except that the ping packets are not going
where they ought to.
-On the bright side, I am getting farther than I have ever gotten before
in running an l2tp tunnel beside a plain one. Before I never got the
SAs to establish because things always seemed to cross their wires.
-Any suggestions on how I might proceed to diagnose this would be most
welcome...
Bob Miller
334-7117/633-3760
http://computerisms.ca
bob at computerisms.ca
Network, Internet, Server,
and Open Source Solutions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090825/ef7b7c8b/attachment.html
More information about the Users
mailing list