[Swan] IKEv1 XAUTH VPN server -- so close and yet so far
Jim Garrison
jhg at jhmg.net
Fri Sep 8 04:01:15 UTC 2017
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 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 given at
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv1_XAUTH_with_PSK)
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.
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 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.
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?
As a side note I see that routing of packets to and from the remote VPN
client does not seem to involve the usual routing mechanisms. There are
no "ipsec_n_" adapters shown by the `ip` command, and no routing table
entries, so I guess I don't understand yet how ipsec and routing
interact. But that's a separate question that I'll have to research.
--
Jim Garrison (jhg at acm.org)
PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88
More information about the Swan
mailing list