<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
Hello,<BR>
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.<BR>
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.<BR>
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.<BR>
<BR>
topology as follows:<BR>
<BR>
Left side:<BR>
192.168.150.0/24<=left-firewall=>216.126.98.194<=>216.126.98.193<=internet<BR>
<BR>
right side: <BR>
internet=>207.189.252.13<=>207.189.252.14<=right-firewall=>192.168.25.0/24 <BR>
<BR>
road warriors:<BR>
internet=>?.?.?.?(dsl router)<=>10.250.10.0/24(ip pool used by l2tpns)<=>local address<BR>
<BR>
1. the problem: <BR>
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.<BR>
<BR>
2. Why I think it should work:<BR>
-ipsec verify checks out on both machines.<BR>
<BR>
-ipsec auto --status contains these lines, and both sides concur that the SA is established:<BR>
<BR>
000 #4: "computerisms-ctfn":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 27214s; newest IPSEC; eroute owner<BR>
000 #4: "computerisms-ctfn" esp.b9589aa@216.126.98.194 esp.9270fcff@207.189.252.14 tun.0@216.126.98.194 <A HREF="mailto:tun.0@207.189.252.14">tun.0@207.189.252.14</A><BR>
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)<BR>
<BR>
-ip route shows a route to the opposing subnet:<BR>
<BR>
leftside:<BR>
216.126.98.192/30 dev eth2 proto kernel scope link src 216.126.98.194 <BR>
10.250.10.0/24 dev tun0 scope link <BR>
192.168.150.0/24 dev eth1 proto kernel scope link src 192.168.150.1 <BR>
192.168.25.0/24 via 216.126.98.193 dev eth2 <BR>
default via 216.126.98.193 dev eth2 <BR>
<BR>
and right side:<BR>
<BR>
207.189.252.12/30 dev eth0 proto kernel scope link src 207.189.252.14 <BR>
192.168.150.0/24 via 207.189.252.13 dev eth0 <BR>
192.168.25.0/24 dev eth1 proto kernel scope link src 192.168.25.1 <BR>
default via 207.189.252.13 dev eth0 <BR>
<BR>
-I have added firewall rules:<BR>
<BR>
left side:<BR>
iptables -I INPUT -m policy --dir in --pol ipsec -p udp -d 216.126.98.194 --dport 1701 -j ACCEPT<BR>
iptables -I INPUT -p udp -d 216.126.98.194 --dport 500 -j ACCEPT<BR>
iptables -I INPUT -p udp -d 216.126.98.194 --dport 4500 -j ACCEPT<BR>
iptables -I INPUT -p 50 -d 216.126.98.194 -j ACCEPT<BR>
iptables -I INPUT -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I INPUT -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT<BR>
iptables -I INPUT -s 192.168.150.0/24 -d 192.168.0.0/16 -j ACCEPT<BR>
iptables -I INPUT -s 192.168.0.0/16 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I FORWARD -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I FORWARD -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT<BR>
iptables -I FORWARD -s 192.168.150.0/24 -d 192.168.0.0/16 -j ACCEPT<BR>
iptables -I FORWARD -s 192.168.0.0/16 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I OUTPUT -s 10.250.10.0/24 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I OUTPUT -s 192.168.150.0/24 -d 10.250.10.0/24 -j ACCEPT<BR>
iptables -I OUTPUT -s 192.168.150.0/24 -d 191.168.0.0/16 -j ACCEPT<BR>
iptables -I OUTPUT -s 192.168.0.0/16 -d 191.168.150.0/24 -j ACCEPT<BR>
<BR>
right side:<BR>
iptables -I INPUT -p udp -d 207.189.252.14 --dport 500 -j ACCEPT<BR>
iptables -I INPUT -p udp -d 207.189.252.14 --dport 4500 -j ACCEPT<BR>
iptables -I INPUT -p 50 -d 207.189.252.14 -j ACCEPT<BR>
iptables -I INPUT -s 192.168.25.0/24 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I INPUT -s 192.168.150.0/24 -d 192.168.25.0/24 -j ACCEPT<BR>
iptables -I FORWARD -s 192.168.25.0/24 -d 192.168.150.0/24 -j ACCEPT<BR>
iptables -I FORWARD -s 192.168.150.0/24 -d 192.168.25.0/24 -j ACCEPT<BR>
iptables -I OUTPUT -s 192.168.25.0/24 -d 191.168.150.0/24 -j ACCEPT<BR>
iptables -I OUTPUT -s 192.168.150.0/24 -d 191.168.25.0/24 -j ACCEPT<BR>
<BR>
3. Things I have tried:<BR>
-ifconfig ethx mtu 1400 <= *I have found this to be necessary for just about every openswan installation I have done.<BR>
<BR>
-monkeying with various config options in ipmasq and ipsec.conf<BR>
--explicitly defining the opposing network as allowed using the virtual_private setting.<BR>
--disabled nat on the right side (need it for the left)<BR>
--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)<BR>
--lots of other things as suggested by man page or google articles<BR>
<BR>
-checked through a barf to look for problems/errors<BR>
<BR>
-scoured for typos in config files<BR>
<BR>
-enabled full pluto debugging and looked for errors/problems<BR>
<BR>
-much googling<BR>
<BR>
4. Points of interest:<BR>
-/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):<BR>
<BR>
Aug 25 13:14:03 fw-ctfn ipsec__plutorun: 104 "computerisms-ctfn" #1: STATE_MAIN_I1: initiate<BR>
Aug 25 13:14:03 fw-ctfn ipsec__plutorun: ...could not start conn "computerisms-ctfn"<BR>
<BR>
-With some debugging turned on, this shows up after the SA is established:<BR>
"computerisms-ctfn" #1: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xb599883d) not found (maybe expired)<BR>
--Andreas Steffen addresses this on a mailing list - looks to be a harmless message.<BR>
<BR>
-ipsec.conf:<BR>
<BR>
left side:<BR>
version 2.0<BR>
<BR>
config setup<BR>
interfaces="%defaultroute"<BR>
plutodebug=none<BR>
klipsdebug=none<BR>
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<BR>
nat_traversal=yes<BR>
<BR>
conn %default<BR>
keyingtries=5<BR>
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem<BR>
auto=add<BR>
<BR>
conn rw-l2tp-ctfn<BR>
left=216.126.98.194<BR>
leftnexthop=216.126.98.193<BR>
leftprotoport=17/%any<BR>
leftrsasigkey=%cert<BR>
right=%any<BR>
rightprotoport=17/%any<BR>
rightrsasigkey=%cert<BR>
pfs=no<BR>
<BR>
conn rw-ctfn<BR>
left=216.126.98.194<BR>
leftnexthop=216.126.98.193<BR>
leftsubnet=192.168.150.0/24<BR>
leftrsasigkey=%cert<BR>
right=%any<BR>
rightrsasigkey=%cert<BR>
pfs=yes<BR>
rightsubnetwithin=192.168.0.0/16<BR>
<BR>
conn computerisms-ctfn<BR>
left=216.126.98.194<BR>
leftnexthop=216.126.98.193<BR>
leftsubnet=192.168.150.0/24<BR>
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem<BR>
right=207.189.252.14<BR>
rightnexthop=207.189.252.13<BR>
rightsubnet=192.168.25.0/24<BR>
rightcert=/etc/ipsec.d/certs/gatelian.computerisms.ca.pem<BR>
auto=start<BR>
# rightid=@gatelian.computerisms.ca<BR>
# leftid=@fw-ctfn.ctfn.ca<BR>
<BR>
<BR>
include /etc/ipsec.d/examples/no_oe.conf<BR>
<BR>
right side:<BR>
version 2.0<BR>
<BR>
config setup<BR>
interfaces="%defaultroute"<BR>
plutodebug=all<BR>
klipsdebug=none<BR>
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<BR>
nat_traversal=yes<BR>
<BR>
conn %default<BR>
keyingtries=5<BR>
auto=add<BR>
leftrsasigkey=%cert<BR>
rightrsasigkey=%cert<BR>
<BR>
conn computerisms-ctfn<BR>
left=216.126.98.194<BR>
leftnexthop=216.126.98.193<BR>
leftsubnet=192.168.150.0/24<BR>
leftcert=/etc/ipsec.d/certs/fw-ctfn.ctfn.ca.pem<BR>
right=207.189.252.14<BR>
rightnexthop=207.189.252.13<BR>
rightsubnet=192.168.25.0/24<BR>
rightcert=/etc/ipsec.d/certs/gatelian.computerisms.ca.pem<BR>
auto=start<BR>
# leftid=@fw-ctfn.ctfn.ca<BR>
# rightid=@gatelian.computerisms.ca<BR>
<BR>
include /etc/ipsec.d/examples/no_oe.conf<BR>
<BR>
6. conclusions/theories/comments<BR>
-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.<BR>
<BR>
-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.<BR>
<BR>
-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. <BR>
<BR>
-Any suggestions on how I might proceed to diagnose this would be most welcome...<BR>
<BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<TT>Bob Miller</TT><BR>
<TT>334-7117/633-3760</TT><BR>
<TT>http://computerisms.ca</TT><BR>
<TT>bob@computerisms.ca</TT><BR>
<TT>Network, Internet, Server,</TT><BR>
<TT>and Open Source Solutions</TT>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>