[Openswan Users] IPSec + RoadWarrior + NAT-T + WinXP. rightsubnet=vhost:%no, %priv kills things

Fri Feb 23 12:00:05 EST 2007

On Fri, 23 Feb 2007, Erik Carlseen wrote:

> Hi, I'm setting up a VPN with OpenSwan 2.4.6 on Vanilla kernel 2.6.18,
> Windows XP, x.509 certificates, and NAT-T. .I've got everything working
> perfectly without NAT-T involved and the "rightsubnet=" config line.
> When I add -the "rightsubnet=" line to the config and try to connect,
> things get screwed up.

That's odd, because packet-wise it shouldnt matter that you have a subnet
defined. It's more likely the other end is rejecting that proposal.
Looking at your config below, you are using the rightsubnet=vhost line,
which is indeed required for NAT-T. How does it "screw up". Any logs?

> If I attempt to connect without NAT, the IPSec negotiates successfully,
> and the XP client starts sending ESP-encapsulated L2TP packets. My
> firewall responds with L2TP packets, but OpenSWAN doesn't encapsulate
> them in IPSec - it just sends them in the clear (tcpdump on the
> firewall's public interface shows this correctly). Crazy.

Are you running NETKEY? then it might just appear your l2tp traffic is not
getting encrypted. Did you confirm with a router in the middle?

> Any help or suggestions would be appreciated.

Logentries of the entire exchange would help.
You can also try to use the hardware setup without NAT, and adding
forceencaps=yes to the connection to trigger NAT encapsulation and see
what that does.

> config setup
>         interfaces="ipsec0=eth0"
>         klipsdebug=none
>         plutodebug=none
>         nat_traversal=yes
>
> virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!172.16.68.0/24,
>
> %v4:!172.20.0.0/14,%v4:!172.24.0.0/13,%v4:!192.168.3.0/24,%v4:!192.168.192.0/18
>
> conn test-rw-x509
>         left=[A.A.A.A]
>         leftcert=(certificate file name)
>         leftrsasigkey=%cert
>         leftprotoport=17/1701
>         right=%any
>         rightprotoport=17/%any
>         rightsubnet=vhost:%no,%priv
>         rightrsasigkey=%cert
>         rightca=%same
>         rightid="(x509 selection)"
>         authby=rsasig
>         pfs=no
>         type=transport
>         keyingtries=1
>         compress=yes
>         disablearrivalcheck=no
>         auto=add
>
> ******************************************************************************
> ******************************************************************************
>
> Typical OpenSWAN output (with NAT):
>
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> responding to Main Mode from unknown peer [B.B.B.B]
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> Main mode peer ID is ID_DER_ASN1_DN: '(RW certificate stuff)'
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> no crl from issuer "(ca stuff)" found (strict=no)
> Feb 22 22:19:03 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56: I
> am sending my cert
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> deleting connection "test-rw-x509" instance with peer [Other Address]
> {isakmp=#55/ipsec=#0}
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509" #51: deleting state
> (STATE_MAIN_R3)
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509" #52: deleting state
> (STATE_MAIN_R3)
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509" #48: deleting state
> (STATE_MAIN_R3)
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509" #55: deleting state
> (STATE_MAIN_R3)
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509" #54: deleting state
> (STATE_MAIN_R3)
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
> Feb 22 22:19:04 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> retransmitting in response to duplicate packet; already STATE_MAIN_R3
> Feb 22 22:19:06 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> retransmitting in response to duplicate packet; already STATE_MAIN_R3
> Feb 22 22:19:10 Firewall pluto[8149]: "test-rw-x509"[3] [B.B.B.B] #56:
> discarding duplicate packet -- exhausted retransmission; already

I believe this is some confusion with previous attempts, making it appear
there are more clients behind the same NAT device. I'd recommend restarting
openswan between your attempts at reconfiguring the client/server connection.

> tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96

tcpdump logs are almost never of any use, because most of the exchange
is encrypted.

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155