Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Mobile IPSEC clients access to LAN?

    Scheduled Pinned Locked Moved IPsec
    11 Posts 2 Posters 3.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • L
      laped
      last edited by

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

      1 Reply Last reply Reply Quote 0
      • B
        bobkoure
        last edited by

        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!

        1 Reply Last reply Reply Quote 0
        • L
          laped
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • L
            laped
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • B
              bobkoure
              last edited by

              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!

              1 Reply Last reply Reply Quote 0
              • L
                laped
                last edited by

                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
                firewall_ipsec.PNG_thumb
                firewall_lan.PNG
                firewall_lan.PNG_thumb
                ipsec_mobileclients.PNG
                ipsec_mobileclients.PNG_thumb
                ipsec_phase1.PNG
                ipsec_phase1.PNG_thumb
                ipsec_phase2.PNG
                ipsec_phase2.PNG_thumb
                ipsec_psk.PNG
                ipsec_psk.PNG_thumb
                virtualip_proxyarp.PNG
                virtualip_proxyarp.PNG_thumb

                1 Reply Last reply Reply Quote 0
                • B
                  bobkoure
                  last edited by

                  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!

                  1 Reply Last reply Reply Quote 0
                  • L
                    laped
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • B
                      bobkoure
                      last edited by

                      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!

                      1 Reply Last reply Reply Quote 0
                      • L
                        laped
                        last edited by

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

                        1. 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.

                        2. 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.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.