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

    [solved] Unable to reach hosts on the other side

    Scheduled Pinned Locked Moved IPsec
    6 Posts 4 Posters 1.7k 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.
    • S
      soul710
      last edited by

      I have successfully set up the IPSec VPN on my pfsense (2.1.5) following this howto: https://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To

      My goal is to be able to reach my privat LAN at home on my iPhone or laptop via internet. I have setup the VPN on my iPhone, and I can successfully connect. However I cannot reach any hosts in my LAN, via e.g. SSH. The very same thing happens when I use the VPN on my macbook. The VPN successfully connects, but no host is accessible. I can neither ping, nor reach via SSH/HTTP etc.

      I have added the following firewall rules in addition to the howto above:

      Also I have added this to the WAN interface rules (I found it in another howto):

      Since the IPSec rule is also logging all packets, I was actually able to see the incoming ICMP/TCP packets when I did a ping or ssh connect. Still no connection gets established.

      10.0.0.0 is my network at home, 10.0.5.0 is the network I picked for the IPSec VPN.

      Can someone please help and tell me what I have to configure in order to access my home lan hosts from the mobile VPN client?

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        IPsec config looks fine, you're passing the traffic. Packet capture on LAN filtered on the 10.0.5.x IP assigned to the VPN client and see what it looks like. Likely an issue with the destination host at that point, maybe its mask is wrong like 255.0.0.0 so it thinks that 10.0.5.x should be local and it fails since it isn't.

        1 Reply Last reply Reply Quote 0
        • H
          Hugh
          last edited by

          You could have been really unlucky and have used a range for your LAN that your ISP gives to your phone on its WAN.

          As someone else mentioned just make sure your LAN masks for your devices are correct as well as your pfSense.

          1 Reply Last reply Reply Quote 0
          • S
            soul710
            last edited by

            @cmb:

            IPsec config looks fine, you're passing the traffic. Packet capture on LAN filtered on the 10.0.5.x IP assigned to the VPN client and see what it looks like. Likely an issue with the destination host at that point, maybe its mask is wrong like 255.0.0.0 so it thinks that 10.0.5.x should be local and it fails since it isn't.

            This is the capture when I ping:

            09:11:35.356199 IP 10.0.5.1 > 10.0.0.5: ICMP echo request, id 44374, seq 3, length 64
            09:11:35.356870 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:11:36.353358 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:11:36.360665 IP 10.0.5.1 > 10.0.0.5: ICMP echo request, id 44374, seq 4, length 64
            09:11:37.353348 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:11:37.364595 IP 10.0.5.1 > 10.0.0.5: ICMP echo request, id 44374, seq 5, length 64
            09:11:38.364580 IP 10.0.5.1 > 10.0.0.5: ICMP echo request, id 44374, seq 6, length 64
            09:11:38.365204 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:11:39.363323 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:11:39.373910 IP 10.0.5.1 > 10.0.0.5: ICMP echo request, id 44374, seq 7, length 64
            

            This is the capture when I ssh:

            09:12:25.933888 IP 10.0.5.1.49235 > 10.0.0.5.22: tcp 0
            09:12:25.934496 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:12:26.933352 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:12:26.937879 IP 10.0.5.1.49235 > 10.0.0.5.22: tcp 0
            09:12:27.933343 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:12:27.941839 IP 10.0.5.1.49235 > 10.0.0.5.22: tcp 0
            09:12:28.942644 IP 10.0.5.1.49235 > 10.0.0.5.22: tcp 0
            09:12:28.943222 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:12:29.933314 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            09:12:29.946103 IP 10.0.5.1.49235 > 10.0.0.5.22: tcp 0
            09:12:30.933302 ARP, Request who-has 10.0.5.1 tell 10.0.0.5, length 46
            
            

            As you expected, the 10.0.0.5 destination host is having a subnet mask of 255.0.0.0:

            eth0      Link encap:Ethernet  HWaddr b8:27:eb:cc:5b:c2  
                      inet addr:10.0.0.5  Bcast:10.255.255.255  Mask:255.0.0.0
            
            

            Now how can/should I fix the whole issue? I'm not too familiar with all this topic. Should I just change the subnet mask to 255.255.255.0 on the internal 10.0.0.5 host, and all other hosts that should be reachable via IPsec accordingly?

            @bc2011:
            I would appreciate if you created a separate thread for your issues, since they seem to completely different to mine, which is pretty confusing for someone who reads this thread.

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

              Done that, sorrry for the mess and good luck with your case.

              1 Reply Last reply Reply Quote 0
              • S
                soul710
                last edited by

                @cmb:

                I just reconfigured the LAN interface on pfsense to use a subnet mask of 255.255.255.0, which got propagated to the clients via DHCP, and now 10.0.0.5 is also having a mask of 255.255.255.0. And now I can fully access this host via IPSec!! :)

                Thanks alot for your help, much appreciated :)

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