4. [Solved] Only partial LAN access!?

[Solved] Only partial LAN access!?

  • C

    Hello everybody!

    As there is now the iOS openVPN client, we have finally started to move away from PPTP to openVPN :-)

    The whole setup of pfSense worked really fine so far (we followed the YouTube Video, which is referenced in a few posts here in the forum) and we could connect fine from
    our PC and iPhone to pfSense in the datacenter.
    I have then tried to access a LAN-IP of pfSense in the datacenter (which is 10.0.2.1), that worked fine. I could also connect to another server with the IP 10.0.2.101.

    Today I wanted to connect to another server (IP: 10.0.2.121) and some other servers, that doesn't work :-(
    Even a PING doesn't reach them, if I connect via PPTP again, everything works just fine  ???
    All those servers are on one switch, so they are accessible (which works fine with PPTP)…

    Here is the info from of the states table as soon as I tried to connecto 10.0.2.121:

    
tcp	10.0.2.121:80 <- 10.0.5.6:49886	CLOSED:SYN_SENT

    Some more info about my network setup:
    Datacenter:
     LAN:
       10.0.2.0/24
     OpenVPN:
       Tunnel Network: 10.0.5.0/24
       Local Network: 10.0.2.0/24

    My client PC gets an IP of e.g. 10.0.5.6.

    Rules:
     WAN-Tab: AutoRule from openVPN Wizard (UDP * * WAN address 41447 * none   OpenVPN WAN wizard )
     OpenVPN-Tab: AutoRule from openVPN Wizard (* * * * * * none   OpenVPN WAN wizard)

    Any suggestions? I am currently at a complete loss here :-(

    Thanks a lot and best regards,

    Chris

    [UPDATE/SOLUTION]
    The solution for me was (thanks to cmb) to create a "Proxy ARP"… Using that, the openVPN Clients can now access all servers in the 10.0.2.0/24-Range perfectly :-)

    0
  • H

    check if those servers have the correct gateway filled in to their interface configuration(gateway should be pfsense)

    0
  • C

    Heper,

    thanks for your reply.

    Yes all servers which have no DHCP assignment, have set DNS and Gateway to 10.0.2.1 (IP of pfSense)…

    And if I connect using PPTP I can access all servers just fine  ???

    Thanks and best regards,

    Christian

    0
  • P

    Do those servers have any special firewall on them that knows to only accept incoming from certain subnets? I guess your PPTP is coming in on some other subnet, which the servers are already configured to accept - maybe the servers are just not allowing 10.0.5.0/24 into them?
    There was another thread just recently where this was the problem.

    0
  • C

    Phil,

    thanks for your reply.
    No they are "simple" servers who accept all connections… One is e.g. a KVM-Card...

    The one thing I don't understand is, why it is working via PPTP perfectly and via OpenVPN only partially....  ???

    And I cannot reinstall pfSense from scratch so easily as I am not in the datacenter... I do have KVM with DeviceRedirection on the pfSense Server, so I could
    install it new, but then I cannot access the WebGUI as that isn't reachable from the WAN-Port...

    So any other ideas? I would really love to get this working ;-)

    Thanks and best regards,

    Chris

    0
  • C

    No need to reinstall.

    The difference between most PPTP and OpenVPN deployments in this regard is OpenVPN clients don't have IPs within the LAN subnet (and really shouldn't, arguably with PPTP as well). That means systems that are missing a default gateway, or have a wrong subnet mask aren't going to be able to communicate with OpenVPN clients while they would with PPTP because no routing is involved. That's the likely cause.

    0
  • C

    Thansk for your reply :-)

    Ok, what could I check to see if everything is ok?

    As stated in the first post, the LAN has a 10.0.2.0/24, the OpenVPN-Clients get a 10.0.5.XXX-IP (local lan setting in openVPN is also 10.0.2.0/24).
    In the PPTP-Settings the clients get a 10.0.8.XXX-IP…

    The OpenVPN-Client can still only reach some internal servers if I force all network traffic through the openVPN tunnel ...

    Thanks a lot for any help :-)

    Best regards,

    Chris

    0
  • C

    The states you posted pretty much guarantee the SYNs are getting passed out and getting no reply. To verify, start a constant ping to one of the IPs that isn't responding, packet capture on LAN filtering on that host's IP. See the traffic leaving there? Then it's going to the host and it isn't responding, or it is responding but gets misrouted (wrong/missing default gateway, wrong subnet mask, routing table entry in error).

    0
  • C

    cmb,

    thanks a lot for your reply.

    I have done as asked:

    
18:09:09.758726 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 5, length 40
18:09:09.764685 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:10.764674 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:11.764682 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:12.078479 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 6, length 40
18:09:16.993667 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 7, length 40
18:09:16.994667 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:17.994676 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:18.994691 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:21.997608 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 8, length 40
18:09:22.004738 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:23.004697 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:24.004703 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:26.999189 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 9, length 40
18:09:27.004724 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:28.004726 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:29.004732 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:31.999711 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 10, length 40
18:09:32.004755 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:33.004750 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:34.004756 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:36.994537 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 11, length 40
18:09:37.004819 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:38.004779 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:39.004779 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:41.998769 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 12, length 40
18:09:42.004802 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:43.004789 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:44.004807 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:47.006118 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 13, length 40
18:09:47.014858 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:48.014833 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:49.014842 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:52.001018 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 14, length 40
18:09:52.004852 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:53.004850 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:54.004840 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:56.993105 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 15, length 40
18:09:56.994870 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:57.994876 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:09:58.994883 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:01.994307 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 16, length 40
18:10:01.994895 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:02.994898 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:03.994903 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:06.998067 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 17, length 40
18:10:07.004923 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:08.004926 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:09.004932 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:11.999210 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 18, length 40
18:10:12.004953 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:13.004948 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:14.004954 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:17.000189 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 19, length 40
18:10:17.005008 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:18.004972 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:19.005007 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:21.998514 IP 10.0.8.6 > 10.0.2.121: ICMP echo request, id 1, seq 20, length 40
18:10:22.005014 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:23.005006 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46
18:10:24.005031 ARP, Request who-has 10.0.8.6 tell 10.0.2.121, length 46

    Whereas 10.0.8.6 is the openVPN Client-IP, 10.0.2.121 is the server…

    I have then done the same with the PPTP-Connection:

    
18:13:19.242341 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 27, length 40
18:13:19.242662 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 27, length 40
18:13:20.251534 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 28, length 40
18:13:20.251830 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 28, length 40
18:13:21.259660 IP 10.0.9.16 > 10.0.2.121: ICMP echo request, id 1, seq 29, length 40
18:13:21.259953 IP 10.0.2.121 > 10.0.9.16: ICMP echo reply, id 1, seq 29, length 40

    Whereas 10.0.9.16 is the PPTP Client-IP, 10.0.2.121 is the server…

    This is the network config of the server:

    IP Address:      10.0.2.121
    Subnet Mask:  255.255.255.0
    Gateway:        10.0.2.1
    DNS Server IP: 10.0.2.1

    Any clues what might go wrong here?

    Thanks a lot for any help :-)

    Best regards,

    Christian

    0
  • C

    Good, that's very telling. The ARP request that's being issued (ARP, Request who-has 10.0.8.6 tell 10.0.2.121) means the host has a wrong subnet mask (not actually 255.255.255.0) or just a plain broken network stack. ARP requests are issued only for IPs that are local on the same subnet. Since 10.0.2.121 is issuing an ARP request for 10.0.8.6, it thinks that is on its local subnet. If it were only configured with 10.0.2.121 with a /24 (255.255.255.0) mask, it would never ARP anything other than 10.0.2.x, and would ARP its default gateway for anything outside that subnet.

    That clearly shows 10.0.2.121 is what's broken, it doesn't tell as clearly why. An errant IP alias on 10.0.8.x, a wrong routing table entry, hard to tell for sure.

    0
  • C

    cmb,

    thanks a lot for your analysis :-)

    But what I still don't understand:
    The problem doesn't only affect one server, I just picked that one for testing purposes…

    And why does it work perfectly OK with PPTP? The PPTP-Client-IP is also not on the 10.0.2.0/24 network, but on 10.0.9.0/24...

    So the server itself can talk from 10.0.2.121 -> 10.0.9.6 without any issues, but not to 10.0.8.6 or 10.0.5.6 (I tested these two network ranges with openVPN) ?

    Couldn't it be some kind of problem in the config/setup of the pfSense itself? It bet that it would work if I also set the PPTP-Range to 10.0.8.0/24 ;-)

    Thanks again a lot for your help!!

    Best regards,

    Chris

    0
  • C

    The firewall has absolutely no control or influence over what hosts on your internal network will ARP. There is 0 possibility for the firewall to cause a device to ARP an IP it should never ARP. I'm sure if you change your PPTP range to 10.0.8.x it'll do the exact same thing (unless mpd proxy ARPs PPTP IPs in that circumstance, I think it'll only do that when they're on the LAN subnet though I'm not 100% sure off the top of my head).

    If you want to work around it without fixing that particular broken device on your network, add a proxy ARP VIP range for 10.0.8.0/24 on LAN. That'll at least work around the broken host that's ARPing things it shouldn't, but I wouldn't, I'd fix the problem on the actual host rather than working around its brokenness. Look at its routing table, and any IP aliases configured.

    Alternatively, change your OpenVPN tunnel network to something in 172.16.0.0/12 and it likely won't pose an issue either, depending on exactly how that device is broken.

    0
  • C

    cmb,

    thanks A LOT! You are the life saver, that worked :-)

    Using the Proxy ARP, I can now connect to all servers in the 10.0.2.0/24-network without any problems :-)

    Now the only thing I have to figure out is how the openVPN-Clients can also access 10.0.1.0/24 and 10.0.3.0/24 … That also worked "out of the box" with PPTP...

    Any hints here for me? Perhaps I am mentally still so "locked" the previous problem that I don't see the (possibly completely easy) solution at the moment g

    Thanks A LOT again and best regards,

    Chris

    0
  • M

    have you tried push route as pfsense suggest you to use?

    0
  • C

    Thanks a lot for your reply  :)

    That did it, now everything works as expected, again a big THANKS to all of you who helped me out here  :)

    Have a nice week!

    Best regards,

    Chris

    0
Locked
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy