LibreSwan IKEv1 XAUTH VPN server -- so close and yet so far
Here's an ASCII-art diagram of my situation
192.168.10.0/24
|
+---+ .7 |
| A |------+ _____
+---+ | ( )
| .254 +---+ Ext IP ( )
+----Ri| R |Re-------( cloud )
| +---+ ( )\ iPhone
| \ (_____) \ +---+
\ ------| |
\ | B |
\ 192.168.11.80 | |
+------VPN-Tunnel---------| |
IKEv1 XAUTH with PSK +---+
Legend:
A - Windows 7
R - CentOS 6.9 acting as a router and iptables firewall,
with LibreSwan installed
Ri - Internal interface of R
Re - External interface of R
B - An iPhone SE with iOS 10 configured to use what Apple
calls "IPSEC" (Cisco) VPN
System R has been a working router/iptables firewall in bridge mode for years.
I need to be able to use MS's Remote Desktop client for iOS to log into system A from iOS device B, and decided to set up a VPN server on R.
You may well ask "Why not just use an SSH client with port forwarding instead"? You would have a really good point, and this is what I used to do, but somewhere around iOS 6 Apple stopped allowing background apps to keep network connections open, making a background SSH tunnel impossible. No current SSH client that claims to support port forwarding can keep a connection open in the background longer than about 90 seconds, so accomplishing my goal requires a VPN.
I set things up using the instructions from LibreSwan
Problem Summary
The VPN connection comes up fine but routing from B to A seems to be broken while everything else, including routing from A to B, seems to work.
Ping Matrix
To
A Ri Re B
A - y y y
From R y - - y
B N y y -
In other words, everybody can ping everybody else EXCEPT B cannot ping anybody inside the 192.168.10.0/24 network, while still being able to ping R's internal network address.
Here is ipsec.conf:
config setup
protostack=netkey
logfile=/var/log/pluto.log
interfaces="%defaultroute"
dumpdir=/var/run/pluto/
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10,%v4:!192.168.10.0/24
keep_alive=60
conn xauth-psk
authby=secret
pfs=no
auto=add
rekey=no
left=%defaultroute
leftsubnet=0.0.0.0/0
rightaddresspool=192.168.11.80-192.168.11.90
right=%any
cisco-unity=yes
modecfgdns1=192.168.10.254
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=file
ike-frag=yes
ikev2=never
Output of ipsec verify:
Verifying installed system and configuration files
Version check and ipsec on-path [OK]
Libreswan 3.15 (netkey) on 2.6.32-696.10.1.el6.x86_64
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [OK]
ICMP default/accept_redirects [OK]
XFRM larval drop [OK]
Pluto ipsec.conf syntax [OK]
Hardware random device [N/A]
Two or more interfaces found, checking IP forwarding [OK]
Checking rp_filter [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto ipsec.secret syntax [OK]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking 'prelink' command does not interfere with FIPSChecking for obsolete ipsec.conf options [OK]
Opportunistic Encryption [DISABLED]
Output of ipsec look:
janus.localdomain Thu Sep 7 20:01:38 PDT 2017
XFRM state:
src xxx.xxx.45.71 dst xxx.xxx.94.61
proto esp spi 0xde18dd2e reqid 16397 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x23faf136fcde2c1b8c31f4cc9fea0003fa2985d2
enc cbc(aes) 0x04c42120ad0357f2406c5a9fdfe3f5ad8fcc45c3ed3aa69aeb1f010f996e3a10
encap type espinudp sport 42703 dport 4500 addr 0.0.0.0
src xxx.xxx.94.61 dst xxx.xxx.45.71
proto esp spi 0x0aa354d9 reqid 16397 mode tunnel
replay-window 32 flag 20
auth hmac(sha1) 0x3ecfa164b8455dfca08b985c8e1b326adba2fa2a
enc cbc(aes) 0xb81e5bfa39b63e493fcce3b2104ee5f2dd2f81fe8a45ec7665dd182493e525f9
encap type espinudp sport 4500 dport 42703 addr 0.0.0.0
XFRM policy:
src 0.0.0.0/0 dst 192.168.11.80/32
dir out priority 3104 ptype main
tmpl src xxx.xxx.94.61 dst xxx.xxx.45.71
proto esp reqid 16397 mode tunnel
src 192.168.11.80/32 dst 0.0.0.0/0
dir fwd priority 3104 ptype main
tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61
proto esp reqid 16397 mode tunnel
src 192.168.11.80/32 dst 0.0.0.0/0
dir in priority 3104 ptype main
tmpl src xxx.xxx.45.71 dst xxx.xxx.94.61
proto esp reqid 16397 mode tunnel
src ::/0 dst ::/0 proto ipv6-icmp type 135
dir fwd priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 135
dir in priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
dir out priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
dir fwd priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 136
dir in priority 1 ptype main
src ::/0 dst ::/0 proto ipv6-icmp type 135
dir out priority 1 ptype main
src ::/0 dst ::/0
dir 4 priority 0 ptype main
src ::/0 dst ::/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0 ptype main
XFRM done
IPSEC mangle TABLES
NEW_IPSEC_CONN mangle TABLES
ROUTING TABLES
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.254
xxx.xxx.45.0/21 dev eth1 proto kernel scope link src xxx.xxx.94.61
169.254.0.0/16 dev eth0 scope link metric 1002
169.254.0.0/16 dev eth1 scope link metric 1003
default via xxx.xxx.45.1 dev eth1
unreachable ::/96 dev lo metric 1024 error -113 mtu 65536
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:a00::/24 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:7f00::/24 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:ac10::/28 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 mtu 65536
unreachable 2002:e000::/19 dev lo metric 1024 error -113 mtu 65536
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113 mtu 65536
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500
NSS_CERTIFICATES
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
pluto.log entries for a connection
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [RFC 3947]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [XAUTH]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Cisco-Unity]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [FRAGMENTATION 80000000]
Sep 7 20:14:39: packet from xxx.xxx.45.71:18317: received Vendor ID payload [Dead Peer Detection]
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: responding to Main Mode from unknown peer xxx.xxx.45.71
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R1: sent MR1, expecting MI2
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 18317: peer be
hind NAT
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: STATE_MAIN_R2: sent MR2, expecting MI3
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
Sep 7 20:14:39: | ISAKMP Notification Payload
Sep 7 20:14:39: | 00 00 00 1c 00 00 00 01 01 10 60 02
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: Main mode peer ID is ID_IPV4_ADDR: '10.148.35.161'
Sep 7 20:14:39: "xauth-psk"[7] xxx.xxx.45.71 #5: switched from "xauth-psk"[7] xxx.xxx.45.71 to "xauth-psk"
Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: deleting connection "xauth-psk" instance with peer xxx.xxx.45.71 {isakmp=#0/ip
sec=#0}
Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: new NAT mapping for #5, was xxx.xxx.45.71:18317, now xxx.xxx.45.71:42703
Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_2
56 integ=OAKLEY_SHA2_256 group=MODP2048}
Sep 7 20:14:39: | event EVENT_v1_SEND_XAUTH #5 STATE_MAIN_R3
Sep 7 20:14:39: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: Sending Username/Password request (XAUTH_R0)
Sep 7 20:14:54: XAUTH: User jhg: Attempting to login
Sep 7 20:14:54: XAUTH: passwd file authentication being called to authenticate user jhg
Sep 7 20:14:54: XAUTH: password file (/etc/ipsec.d/passwd) open.
Sep 7 20:14:54: XAUTH: checking user(jhg:xauth-psk)
Sep 7 20:14:54: XAUTH: User jhg: Authentication Successful
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: XAUTH: xauth_inR1(STF_OK)
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_XAUTH_R1 to state STATE_MAIN_R3
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute INTERNAL_ADDRESS_EXPIRY received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute APPLICATION_VERSION received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_BANNER received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute MODECFG_DOMAIN received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_DNS received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_INC received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SPLIT_EXCLUDE received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_DO_PFS received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_SAVE_PW received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_FW_TYPE received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_BACKUP_SERVER received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: Unsupported modecfg long attribute CISCO_UNKNOWN_SEEN_ON_IPHONE received.
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: modecfg_inR0(STF_OK)
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: transition from state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: STATE_MODE_CFG_R1: ModeCfg Set sent, expecting Ack
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #5: the peer proposed: 0.0.0.0/0:0/0 -> 192.168.11.80/32:0/0
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: responding to Quick Mode proposal {msgid:9b886838}
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: us: 0.0.0.0/0===xxx.xxx.94.61[MS+XS+S=C]
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: them: xxx.xxx.45.71[10.148.35.161,+MC+XC+S=C]===192.168.11.80/32
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 tunnel mode
{ESP/NAT=>0x0e7958fe <0xbbd3b5cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg}
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Sep 7 20:14:55: "xauth-psk"[8] xxx.xxx.45.71 #6: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP/NAT=>0x0e7958fe <0xbbd3b5
cf xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=xxx.xxx.45.71:42703 DPD=passive XAUTHuser=jhg}
To re-summarize: The VPN connects and authenticates OK, no errors or anything fishy in pluto.log or /var/log/secure, but client B cannot get its packets routed to the A subnet, even though A hosts CAN ping B.
One thing I did try was changing the interfaces line in `ipsec.conf' to
interfaces="%defaultroute ipsec0=eth0"
but this had no effect, and did not create an interface called ipsec0.
Question
What do I need to change in my config to get routing to happen correctly, so that B can communicate with hosts on the internal subnet?
Side Note/Additional Information
I notice that routing of packets to and from the remote VPN client does not seem to involve the usual routing mechanisms. There are no ipsecn adapters shown by the ip command, so I guess I don't understand yet how ipsec and routing interact.
The router/firewall R has masquerading enabled for outgoing traffic:
iptables-restore NAT table section (eth1 is external adapter)
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o eth1 -j MASQUERADE
iptables-restore input filter:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i eth1 -j INPUT_FILTER
:INPUT_FILTER - [0:0]
-A INPUT_FILTER -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT_FILTER -p udp --dport 500 -j ACCEPT
-A INPUT_FILTER -p udp --dport 1701 -j ACCEPT
-A INPUT_FILTER -p udp --dport 4500 -j ACCEPT
-A INPUT_FILTER -p udp -m policy --dir in --pol ipsec -m udp --dport 1701 -j ACCEPT
-A INPUT_FILTER -p 50 -j ACCEPT
-A INPUT_FILTER -p 51 -j ACCEPT
-A INPUT_FILTER -j DROP
But since there are no VPN adapters I'm not sure what I'd change here.
Solution 1:
The solution to this problem demonstrates the critical importance of having a correct mental model of what's going on.
Simply put, the ipsec tunnel was working just fine, but I needed to tweak some firewall rules both on the router (R above) and the Windows machine (A above).
I had assumed/guessed that ipsec was providing some kind of virtual network interface to represent the tunnel, but for some reason I could not see it, and didn't know where to find it. I finally found the command
ipsec_tncfg (5) - lists IPSEC virtual interfaces attached to real interfaces
but running this gave
[jhg@janus ~]$ sudo ipsec tncfg
/usr/libexec/ipsec/tncfg: NETKEY does not support virtual interfaces.
After some methodical analysis of packet flow I had the epiphany:
ipsec completely hides itself, and all tunneled traffic looks like it is coming in un-tunneled from the external world, but with RFC-1918 private source addresses.
Normally you would never see incoming traffic with an RFC-1918 source address, and my iptables FORWARD chain was configured to silently drop everything that wasn't --state RELATED,ESTABLISHED.
So, the simple answer is to add a rule in the FORWARD chain that allows packets from the addresspool range to be forwarded. In iptables-restore format:
# THIS IS A TEMPORARY HACK TO DEMONSTRATE THAT IT FIXES THE ISSUE
# IN A PRODUCTION ENVIRONMENT THIS WOULD BE A SECURITY RISK
-A FORWARD_FILTER -i eth1 -s 192.168.11.64/26 -o eth0 -d 192.168.10.0/24 -j ACCEPT
I understand that this is a relatively minor (but non-zero) security risk as it now allows someone to place a rogue host on the subnet at my ISP, configured in the 192.168.11.64/26 range and get past my firewall. I also know there are options in iptables to restrict this hole to ipsec only (--m policy --pol ipsec ...) but I have to read the man page and do some research. If I can't get that to work it's a separate question. When I get it working I'll come back and update this answer.
That didn't quite work, the packets now made it as far as host A but were not being responded to. But that was easily explained because Windows Firewall didn't recognize the addresspool subnet, so adding a firewall rule there finally made everything work as expected.
Next up is to move the addresspool to overlay part of the internal LAN subnet so I can dispense with the Windows Firewall rule. But that's for another day.