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

[Erik Carlseen]

Paul,

Thanks for your quick and detailed response! Hopefully I can clear up
some confusion from my initial post while I attempt to implement some of
your suggestions.

-Erik

> 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?
>
>   

Ok, after some additional research I noticed that my ISP appears to be 
blocking these packets from the Internet at the cable modem (I put a hub 
and a packet sniffer between my cable modem and the NAT router, and 
verified that the packets were not making it to the NAT router. From 
there decreased the TTL on the outbound packets from the main firewall 
using iptables and watched for ICMP timeout messages until I figured out 
where they were being lost).

>> 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?
>
>   
Running KLIPS. The other endpoint is receiving the unencapsulated L2TP
traffic when I try without NAT.

>> 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.
>
>   
Could you recommend some logging settings other than "all" that may be
useful? With as much traffic going through this device, "all" generates
about a megabyte of output per minute. If not, I'll see what I can
squeak out. I'll try the "forceencaps" suggestion as well.

>> 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.
>
>   
The NAT device in question is set up specifically to test the ability to
connect, and there is exactly one device (the test roadwarrior client)
behind it. There may be some detrius from a previous attempt of the same
roadwarrior client through a different NAT device in this specific
example. In any case, I've restarted OpenSWAN many, many times during my
tests. The NAT connection consistently dies with my firewall allegedly
sending R3 packets that are never seen again, and the roadwarrior client
resending its (I'm guessing) R2 packets.

>> 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.
>
>   
As mentioned above, I included them so that I could show explicitly
which packets were not making it to the destination NAT device. I later 
found that it was an ISP issue on the roadwarrior side.


> Paul
>