Mobile IPSEC clients access to LAN?

bobkoure

I have mobile clients connecting using https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

My win10 VPN built-in client indicates 'connected', but I cannot ping my PFSense box.

I set the IPSEC mobile client assigned range to something other than a subnet of my LAN.
Do I need to change this? Or should I instead create a route?

My firewall/rules/ipsec already contains an any/any/any rule, so I don't expect the issue to be there.

Thanks!

laped

One way you can do this is to create a ProxyARP rule and add the network mobile client pool to the LAN interface.

bobkoure

Thanks for the response!

I'm still a bit puzzled - and don't have it working (sigh)
I go to firewall/virtual IPs, create a new one
interface - LAN
address type - network
address(es) - same as the range IPSEC is handing to mobile clients (172.16.48.0/24)
selected radio button Proxy ARP

Saved. …and I still can't ping anything on my LAN segment (172.16.52.0/24)

FWIW, as part of my trying to get this working, I had created a single address virtual IP (172.16.48.1). I can ping that, get a response. I'd guess that that was the firewall responding, but I can't get to the web UI via that address.

I'm using EAP-MSCHAPv2 as that, along with exporting / importing a CA cert, lets me connect using the Win10 client, plus the android strongSWAN app.

Any ideas?

Thanks again!

laped

Which subnet are you using for the mobile clients?. It has to be a 172.16.0.0/16. In order to use proxyARP you have to seperate the mobile pool from the LAN segment, which you have done fine. So check the subnet and maybe use some package capture on the pfsense diagnostic page and capture on LAN and IPSec to see how far the package traverse. Checking the firewall can also help for troubleshooting. :D

For some time I have considered making a guide using IPSec/IKEv2 with PSK and ProxyARP. Sounds like it could be useful for some to get started. I'll try to make one tomorrow.

laped

Update. you will need the 172.16.0.0/16 subnet for the mobile clients if the mobile clients should ping each other. If they only should have acess to the LAN segment then a 172.16.52.0/24 subnet should be enough.

bobkoure

Using diagnostics/packet capture, then selecting interface IPSec, everything else as "capture everything", I get

23:45:52.630629 (authentic,confidential): SPI 0xc6dfe8a7: IP 172.16.48.1 > 172.16.52.211: ICMP echo request, id 1, seq 1, length 64
23:45:53.651139 (authentic,confidential): SPI 0xc6dfe8a7: IP 172.16.48.1 > 172.16.52.211: ICMP echo request, id 1, seq 2, length 64
23:45:54.646710 (authentic,confidential): SPI 0xc6dfe8a7: IP 172.16.48.1 > 172.16.52.211: ICMP echo request, id 1, seq 3, length 64

172.16.48.1 is my connected client (android / strongSwan) I'm pinging 172.16.52.211 (a laptop plugged into the LAN port).

If I setup packet capture for interface LAN, and protocol ICMP, and ping again from my VPNed client
I get no packets.

Looks like the packets are making it to the firewall, but are not being passed onto the LAN segment.
Time for me to revisit ProxyARP, I guess.

I've set my virtual IP to 172.16.48.0/20 (so 172.16.48.1 to 172.16.63.254)
Same results.

I then set my virtual IP to 172.16.0.0/16
Same results.

I'm pretty puzzled. Any ideas?

Thanks!

laped

I just tried to slam a small guide together with a working setup. In this setup I have a mobile client (rwclient1), a pfsense and a LAN PC. rwclient and lan pc are just a cloned fedora 26.

The rwclient is connecting to the pfsense and afterwards it can ping the lan pc and the lan pc can ping the rwclient as shown. I have tried to take screenshots of the pfsense configuration and pasted the ipsec configurations for the rwclient too. I hope this will help you out :)

pfsense - WAN 192.168.2.101/24, LAN: 192.168.16.1/24

rwclient1 WAN 192.168.2.205/24

[test@localhost ~]$ sudo strongswan statusall
[sudo] password for test:
Status of IKE charon daemon (strongSwan 5.6.0, Linux 4.12.8-300.fc26.x86_64, x86_64):
uptime: 18 minutes, since Oct 30 23:08:33 2017
malloc: sbrk 2838528, mmap 0, used 744240, free 2094288
worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon pkcs11 tpm aesni aes des rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt fips-prf gmp curve25519 chapoly xcbc cmac hmac ctr ccm gcm curl sqlite attr kernel-libipsec kernel-netlink resolve socket-default farp stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp eap-aka-3gpp2 eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-imc tnc-imv tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp led duplicheck unity
Listening IP addresses:
192.168.2.205
192.168.124.1
Connections:
roadwarrior: 192.168.2.205…192.168.2.101 IKEv2, dpddelay=900s
roadwarrior: local: [rwclient1] uses pre-shared key authentication
roadwarrior: remote: [roadwarriorvpn-1] uses pre-shared key authentication
roadwarrior: child: dynamic === 192.168.16.0/24 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
roadwarrior[1]: ESTABLISHED 17 minutes ago, 192.168.2.205[rwclient1]…192.168.2.101[roadwarriorvpn-1]
roadwarrior[1]: IKEv2 SPIs: 98c147175fcfc25c_i* 9d56cb4bba58016e_r, pre-shared key reauthentication in 7 hours
roadwarrior[1]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_512/ECP_521
roadwarrior{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: bcbfc911_i cf87283c_o
roadwarrior{1}: AES_GCM_16_256, 1512 bytes_i (18 pkts, 1027s ago), 1512 bytes_o (18 pkts, 1027s ago), rekeying in 2 hours
roadwarrior{1}: 10.75.16.1/32 === 192.168.16.0/24

[test@localhost ~]$ sudo cat /etc/strongswan/ipsec.conf

/etc/ipsec.conf - strongSwan IPsec configuration file

config setup
#charondebug="cfg 4, dmn 4, ike 4, net 4"
charondebug="cfg 1, dmn 2, ike 1"

conn %default
ikelifetime=28800s
lifetime=10800s
margintime=600s
keyingtries=1
keyexchange=ikev2
type=tunnel
dpdaction=clear
dpddelay=900s
ike=aes256gcm128-sha512-ecp521!
esp=aes256gcm128-ecp521!
authby=psk

Configuration notes:

left = local, right = remote

leftid/rightid: ID payload exchanged during IKE (certificate: DN or

! in ike and esp only allow specified cypher suites (no NSA downgrade)

TFC: Traffic Flow Confidentiality

DPD: Dead Peer Detection

conn roadwarrior
left=192.168.2.205
leftid=rwclient1
leftsourceip=%config
leftfirewall=no
right=192.168.2.101
rightid=roadwarriorvpn-1
rightsubnet=192.168.16.0/24
tfc=1280
auto=add

[test@localhost ~]$ sudo cat /etc/strongswan/ipsec.secrets

ipsec.secrets - strongSwan IPsec secrets file

rwclient1 : PSK password1

Ping from rwclient to LAN PC
[test@localhost ~]$ ping 192.168.16.2
PING 192.168.16.2 (192.168.16.2) 56(84) bytes of data.
64 bytes from 192.168.16.2: icmp_seq=1 ttl=63 time=1.10 ms
64 bytes from 192.168.16.2: icmp_seq=2 ttl=63 time=0.611 ms
64 bytes from 192.168.16.2: icmp_seq=3 ttl=63 time=0.585 ms

LAN PC on pfsense LAN network: 192.168.16.2/24

ping from LAN PC to mobile rwclient1
[test@localhost ~]$ ping 10.75.16.1
PING 10.75.16.1 (10.75.16.1) 56(84) bytes of data.
64 bytes from 10.75.16.1: icmp_seq=1 ttl=63 time=0.468 ms
64 bytes from 10.75.16.1: icmp_seq=2 ttl=63 time=0.433 ms
64 bytes from 10.75.16.1: icmp_seq=3 ttl=63 time=0.459 ms
64 bytes from 10.75.16.1: icmp_seq=4 ttl=63 time=0.441 ms

firewall_ipsec.PNG_thumb

firewall_lan.PNG_thumb

ipsec_mobileclients.PNG_thumb

ipsec_phase1.PNG_thumb

ipsec_phase2.PNG_thumb

ipsec_psk.PNG_thumb

virtualip_proxyarp.PNG_thumb

bobkoure

Thanks!
BTW, I could not use PSK as I have android mobile clients, so I used IKEv2 (as suggested in the pfSense Book)
BTW2: easiest way to get self-signed CA files to Android clients was Google Drive

Looks like the secret might have been making sure the Virtual IP / Proxy ARP is the exact same IP and netmask as specified in mobile client configuration. I was using a superset (clients assigned 172.16.48.50/28, virtual IP/Proxy ARP 172.16.48.0/24) and that did not work.

Pings work but other protocols do not. Trying protocols other than ping cause connection to stop working (but doesn't disconnect the mobile client). This happens with the 2 'obvious' protocols to try: RDP and SMB. I ran a packet capture of a ping, then an attempted SMB connection from VPN to LAN workstation

capturing IPSEC

02:18:14.990827 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 82, seq 1, length 64
02:18:14.991148 (authentic,confidential): SPI 0xcb516e52: IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 82, seq 1, length 64
02:18:16.032518 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 82, seq 2, length 64
02:18:16.032894 (authentic,confidential): SPI 0xcb516e52: IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 82, seq 2, length 64
02:18:17.069525 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 82, seq 3, length 64
02:18:17.069895 (authentic,confidential): SPI 0xcb516e52: IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 82, seq 3, length 64
02:19:33.020402 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:19:34.022475 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:19:36.031971 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:19:40.040799 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:19:48.051108 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:20:03.093343 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34252 > 172.16.52.36.445: tcp 0
02:20:04.083311 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34252 > 172.16.52.36.445: tcp 0
02:20:04.102718 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34251 > 172.16.52.36.445: tcp 0
02:20:06.119915 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34252 > 172.16.52.36.445: tcp 0
02:20:10.097454 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34252 > 172.16.52.36.445: tcp 0
02:20:13.110143 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34253 > 172.16.52.36.445: tcp 0
02:20:14.113641 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34253 > 172.16.52.36.445: tcp 0
02:20:16.123181 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34253 > 172.16.52.36.445: tcp 0
02:20:20.136219 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34253 > 172.16.52.36.445: tcp 0
02:20:23.144261 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34258 > 172.16.52.36.445: tcp 0
02:20:24.147059 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34258 > 172.16.52.36.445: tcp 0
02:20:26.141505 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34258 > 172.16.52.36.445: tcp 0
02:20:30.162412 (authentic,confidential): SPI 0xc2f2b8e6: IP 172.16.48.1.34258 > 172.16.52.36.445: tcp 0

then of the LAN interface (BTW, pings fail after I attempt SMB - and fail. This is after a disconnect / reconnect


// trimmed junk prior to ping
02:43:40.730778 IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 84, seq 1, length 64
02:43:40.731207 IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 84, seq 1, length 64
02:43:41.768478 IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 84, seq 2, length 64
02:43:41.768866 IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 84, seq 2, length 64
02:43:42.820515 IP 172.16.48.1 > 172.16.52.36: ICMP echo request, id 84, seq 3, length 64
02:43:42.820878 IP 172.16.52.36 > 172.16.48.1: ICMP echo reply, id 84, seq 3, length 64
02:43:43.506837 IP 172.16.52.36.50811 > 172.217.10.131.443: tcp 1
02:43:43.521679 IP 172.217.10.131.443 > 172.16.52.36.50811: tcp 0
02:43:43.812123 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 0
02:43:43.827434 IP 192.241.178.140.443 > 172.16.52.36.50815: tcp 0
02:43:43.827719 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 0
02:43:43.828137 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 517
02:43:44.028309 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 517
02:43:47.069097 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 517
02:43:53.069535 IP 172.16.52.36.50815 > 192.241.178.140.443: tcp 517
02:43:57.364256 IP 172.16.52.36.50782 > 199.96.57.6.443: tcp 1
02:43:57.385189 IP 199.96.57.6.443 > 172.16.52.36.50782: tcp 0
02:43:58.373367 IP 172.16.52.36.65042 > 157.56.149.60.3544: UDP, length 61
02:43:58.406844 IP 157.56.149.60.3544 > 172.16.52.36.65042: UDP, length 109

I've been digging though the downloaded captures with Wireshark. Nothing jumps out. Got any ideas?

Thanks!

laped

Iam not sure what happens. Can you ping with a higher packet size?

Usage: ping [-aAbBdDfhLnOqrRUvV64] [-c count] [-i interval] [-I interface]
[-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos]
[-s packetsize] [-S sndbuf] [-t ttl] [-T timestamp_option]
[-w deadline] [-W timeout] [hop1 …] destination

bobkoure

Pings of up to 1000b succeed, those of 2000b fail. Downloading the capture and looking at it with wireshark, the difference seems to be that the 2000b ones are fragmented.

I have no problems connecting from ipsec to the pfSense box at its LAN address. 80, 443 and 23 all work fine. Sadly, my test machine on the LAN is win10 - and msoft has removed the telnet server that used to be on win.

I can ping the firewall LAN address ('any' rule) - can ping up to 9000b, 10000b fails. Using wireshark, all of these appear to be fragmented.

Thanks!

laped

Iam not 100% sure how your setup are configured but you must be close if you can ping stuff.

Try play with the iperf between ipsec client and lan pc and see how that works out. Maybe its an MTU fragmentation issue you are seeing and clamping the ipsec packets to something like 1450 with MSS clamping in the ipsec advanced tab could help.
Use the firewall and ipsec log and try to figure out why packets are not showing up in the package capture.

PS Just tested with my example setup and a http web server on the lan pc. And the client can without problem load it.