OpenVPN client can ping but not access server on LAN



  • Hi All,

    I have a OpenVPN server on pfSense 2.4.5-RELEASE-p1 with a tunnel of 192.168.10.0/24 that goes to a local network 192.168.2.0/24 (OPT1) & 192.168.1.0/24 (LAN).

    WAN.PNG LAN.PNG OPT1.PNG OPENvpn.PNG

    I have a security system I'm trying to access at 192.168.2.10 via it's web interface but are unable to. Once I connect I can see the route in the clients route table to 192.168.2.0/24 via the gateway 192.168.10.1. I can also ping the security system from the client. When I try go to 192.168.2.10:85 in the web browser it just hangs.

    If I open up the firewall and port forward ports 85 and 9000 from the WAN to the security system I have no issues.

    The same thing goes for the pfSense web GUI from the client, via port forward, no issues. Via the VPN, it just times out, even though I can ping pfSense on 192.168.1.1.

    The goal is to isolate the security system on it's own LAN without a gateway as I don't trust the security systems firmware to be secure enough for direct external access.

    The VPN was setup using the wizard.

    Thanks for taking the time to read,
    Andy.



  • I did a packet capture on pfSense for 192.168.0.0/16 on port 85, this is what I got.

    The Client is 192.168.10.2, and the security system is 192.168.2.10.

    11:10:52.215258 IP (tos 0x0, ttl 128, id 30654, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.2.53680 > 192.168.2.10.85: Flags [R.], cksum 0x4bfd (correct), seq 2501817268, ack 3038185094, win 0, length 0
    11:10:52.215334 IP (tos 0x0, ttl 128, id 30655, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.10.2.53697 > 192.168.2.10.85: Flags [S], cksum 0xc1b5 (correct), seq 3351086733, win 65535, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
    11:10:52.216080 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [S.], cksum 0x6e52 (correct), seq 1476298976, ack 3351086734, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    11:10:52.333288 IP (tos 0x0, ttl 128, id 30656, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.10.2.53697 > 192.168.2.10.85: Flags [.], cksum 0x1d35 (correct), seq 1, ack 1, win 1024, length 0
    11:10:52.337620 IP (tos 0x0, ttl 128, id 30657, offset 0, flags [DF], proto TCP (6), length 323)
    192.168.10.2.53697 > 192.168.2.10.85: Flags [P.], cksum 0x702a (correct), seq 1:284, ack 1, win 1024, length 283
    11:10:52.338301 IP (tos 0x0, ttl 63, id 14540, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [.], cksum 0x1f2d (correct), seq 1, ack 284, win 237, length 0
    11:10:52.338772 IP (tos 0x0, ttl 63, id 14541, offset 0, flags [DF], proto TCP (6), length 148)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0xfb00 (correct), seq 1:109, ack 284, win 237, length 108
    11:10:52.693167 IP (tos 0x0, ttl 63, id 14542, offset 0, flags [DF], proto TCP (6), length 910)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0x0941 (correct), seq 109:979, ack 284, win 237, length 870
    11:10:53.048076 IP (tos 0x0, ttl 63, id 14543, offset 0, flags [DF], proto TCP (6), length 1018)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0xe588 (correct), seq 1:979, ack 284, win 237, length 978
    11:10:53.758153 IP (tos 0x0, ttl 63, id 14544, offset 0, flags [DF], proto TCP (6), length 1018)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0xe588 (correct), seq 1:979, ack 284, win 237, length 978
    11:10:55.176161 IP (tos 0x0, ttl 63, id 14545, offset 0, flags [DF], proto TCP (6), length 1018)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0xe588 (correct), seq 1:979, ack 284, win 237, length 978
    11:10:58.016196 IP (tos 0x0, ttl 63, id 14546, offset 0, flags [DF], proto TCP (6), length 1018)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [P.], cksum 0xe588 (correct), seq 1:979, ack 284, win 237, length 978


  • LAYER 8 Global Moderator

    @Andy142 said in OpenVPN client can ping but not access server on LAN:

    The goal is to isolate the security system on it's own LAN without a gateway

    If you want to talk to a system without a gateway from a remote network, then you would need to do a source nat (outbound nat in pfsense on its interface connected to the device)

    So for example I talk to this 192.168.0.101 IP from my vpn, and device on that IP has no gateway set..

    The outbound (source nat) makes it looks to that device like the traffic came from pfsense IP on that vlan.

    sourcenat.png

    sniff via the vpn interface - you can see my remote client from 10.0.200.2 is sending to 192.168.9.101

    06:33:39.977012 IP 10.0.200.2 > 192.168.9.101: ICMP echo request, id 13601, seq 0, length 64
    06:33:39.977322 IP 192.168.9.101 > 10.0.200.2: ICMP echo reply, id 13601, seq 0, length 64
    06:33:40.872795 IP 10.0.200.2 > 192.168.9.101: ICMP echo request, id 13601, seq 1, length 64
    06:33:40.873109 IP 192.168.9.101 > 10.0.200.2: ICMP echo reply, id 13601, seq 1, length 64
    

    But if I sniff on the lan interface while doing the same ping test, it looks like traffic coming from pfsense lan interface 192.168.9.253

    06:37:30.483321 IP 192.168.9.253 > 192.168.9.101: ICMP echo request, id 11550, seq 0, length 64
    06:37:30.483568 IP 192.168.9.101 > 192.168.9.253: ICMP echo reply, id 11550, seq 0, length 64
    06:37:31.374898 IP 192.168.9.253 > 192.168.9.101: ICMP echo request, id 11550, seq 1, length 64
    06:37:31.375172 IP 192.168.9.101 > 192.168.9.253: ICMP echo reply, id 11550, seq 1, length 64
    


  • I may be off with my terminology so to clarify, the OPT1 network has only the security system on it and I don't want it to have internet access.

    I have setup an outbound NAT as you recommended but still no luck unfortunately.

    NAT.PNG

    Is the fact I can ping the device but not connect to it significant?


  • LAYER 8 Global Moderator

    Do the simple test I did in my edit above.. Sniffing on openvpn interface I see the vpn client sending traffic

    Then on the interface this device is connected to.. see the traffic get natted.

    Using some mask of /16 would be saying the both your source and dest are on the same network - which they are not..

    If you sniffing on the openvpn and you saw return traffic.. Then you got something else going on to why your not connecting. Pfsense sent the traffic back, which would be impossible really if the client has no gateway.. Unless you created a specific route back to pfsense opt1 interface to get to your vpn network? On that host.

    This shows you saw answer back

    192.168.10.2.53697 > 192.168.2.10.85: Flags [S], cksum 0xc1b5 (correct), seq 3351086733, win 65535, options [mss 1360,nop,wscale 8,nop,nop,sackOK], length 0
    11:10:52.216080 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.2.10.85 > 192.168.10.2.53697: Flags [S.], cksum 0x6e52 (correct), seq 1476298976, ack 3351086734, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    

    See the Syn send [S] and then the Syn,Ack back [S.]



  • Okay that makes sense, here are my results:

    For OpenVPN interface for host 192.168.10.2 (client)

    11:42:52.942806 IP 192.168.10.2 > 192.168.2.10: ICMP echo request, id 1, seq 37, length 40
    11:42:52.943393 IP 192.168.2.10 > 192.168.10.2: ICMP echo reply, id 1, seq 37, length 40
    11:42:53.875418 IP 192.168.10.2 > 192.168.2.10: ICMP echo request, id 1, seq 38, length 40
    11:42:53.876096 IP 192.168.2.10 > 192.168.10.2: ICMP echo reply, id 1, seq 38, length 40

    For OPT1 interface looking at Host 192.168.2.10 (security system)

    11:44:29.215472 IP 192.168.10.2 > 192.168.2.10: ICMP echo request, id 1, seq 41, length 40
    11:44:29.216103 IP 192.168.2.10 > 192.168.10.2: ICMP echo reply, id 1, seq 41, length 40
    11:44:30.241505 IP 192.168.10.2 > 192.168.2.10: ICMP echo request, id 1, seq 42, length 40
    11:44:30.242146 IP 192.168.2.10 > 192.168.10.2: ICMP echo reply, id 1, seq 42, length 40

    It doesn't look like the NAT is doing anything?


  • LAYER 8 Global Moderator

    No its not..

    Btu you show a response.. How would you see a response if the security system has no gateway? 192.168.10 is not on its network 192.168.2/24

    Did you set a specific route on the security system for 192.168.10/24?



  • That's what has been throwing me.

    There are no static routes or bridges setup. Only thing I have linking them is the "Local Network" of 192.168.2.0/24 in the OpenVPN config.

    Here is the interface setup for OPT1.

    OPT1.PNG



  • @Andy142 , Can I see a screenshot of your Mappings?
    Go to Firewall > NAT > Outbound



  • Sure thing, here you go.

    mappings.PNG



  • @Andy142 , Do you how to make Aliases?



  • @AKEGEC Not really... Sorry


  • LAYER 8 Global Moderator

    Your dest is wrong in that outbound nat.. your vpn client is coming from 192.168.10 right, and he is talking to your security device on 192.168.2.x right?

    So your outbound nat dest would be the 192.168.2 network.. not 192.168.10

    The point of the outbound nat to talk to a device on a 192.168.2 network that has no gateway on the device, is to make the traffic look like its coming from its own network 192.168.2..

    The destination is the opt1 network.. 192.168.2

    client 192.168.10.2 --- vpn ---192.168.10.1 (pfsense) 192.168.2.1 --- 192.168.2.x

    So you want to nat this 192.168.10 traffic to look like it came from 192.168.2.1, so 2.x knows how to talk back to it without a gateway..



  • Go to Firewall > Aliases > +Add

    Name: Private OPT1 or bla bla bla
    Type: Network(s)
    Network or FQDN: 192.168.10.2-192.168.10.254
    If your OPT1 IP interface is 192.168.10.1, you must excluded your OPT1 interface ip address.
    Press Add Network button



  • I regijied the outbound, here are the results

    On the OpenVPN Interface

    12:40:36.930315 IP 192.168.10.2 > 192.168.2.10: ICMP echo request, id 1, seq 69, length 40
    12:40:36.931039 IP 192.168.2.10 > 192.168.10.2: ICMP echo reply, id 1, seq 69, length 40

    The OPT1 interface

    12:42:01.418506 IP 192.168.2.1 > 192.168.2.10: ICMP echo request, id 50048, seq 73, length 40
    12:42:01.419125 IP 192.168.2.10 > 192.168.2.1: ICMP echo reply, id 50048, seq 73, length 40

    Looks like it's replying to the default gateway now at least.


  • LAYER 8 Global Moderator

    Yup that looks good..

    You should be able to talk to that device now on anything not just icmp

    To that device any traffic coming from your vpn will just look like its coming from pfsense 2.1, which is on its own network and it can talk to.

    This should also circumvent any device firewalls that would prevent talking to some service from a different network.



  • @AKEGEC What do I put in the second box that comes up after pressing "Add network"? Or did you mean "save"?


  • LAYER 8 Global Moderator

    Have no idea why he wants you to create an alias, there is no need for one in such a setup.



  • @johnpoz Still not getting a response from the security system....


  • LAYER 8 Global Moderator

    Well do you sniff test again.. Do you see traffic going to your security system looking like its coming from 2.1, do you see a response - does the response go back to yoru vpn client?

    If you see traffic going back over the vpn to your vpn client - its not a pfsense issue.



  • @johnpoz This is when trying to access the webpage:

    On the OpenVPN interface

    12:54:58.643002 IP 192.168.10.2.63027 > 192.168.2.10.85: tcp 0
    12:55:00.483117 IP 192.168.10.2.63202 > 192.168.2.10.85: tcp 0
    12:55:00.483881 IP 192.168.2.10.85 > 192.168.10.2.63202: tcp 0
    12:55:00.868709 IP 192.168.10.2.63202 > 192.168.2.10.85: tcp 0
    12:55:00.868786 IP 192.168.10.2.63202 > 192.168.2.10.85: tcp 283
    12:55:00.869464 IP 192.168.2.10.85 > 192.168.10.2.63202: tcp 0
    12:55:00.870122 IP 192.168.2.10.85 > 192.168.10.2.63202: tcp 108
    12:55:01.651781 IP 192.168.2.10.85 > 192.168.10.2.63202: tcp 870

    The OPT1 interface

    12:53:08.909190 IP 192.168.2.1.63368 > 192.168.2.10.85: tcp 0
    12:53:08.909830 IP 192.168.2.10.85 > 192.168.2.1.63368: tcp 1440
    12:53:09.143689 IP 192.168.2.10.85 > 192.168.2.1.37840: tcp 0
    12:53:09.170709 IP 192.168.2.10.85 > 192.168.2.1.51729: tcp 0

    Looks like everything should be working....


  • LAYER 8 Global Moderator

    Not doesn't look right to be honest.. Looks like you sent 2 syns maybe, you have 2 different source ports there.

    Well clearly your seeing answers back to your vpn client.. I would open them in say wireshark, make sure its not the security system sending back F off with a RST..

    But if you see return traffic going back to the client over the vpn - pfsense is doing exactly what it suppose to..

    This is traffic 2 3 different source ports

    12:53:08.909830 IP 192.168.2.10.85 > 192.168.2.1.63368: tcp 1440
    12:53:09.143689 IP 192.168.2.10.85 > 192.168.2.1.37840: tcp 0
    12:53:09.170709 IP 192.168.2.10.85 > 192.168.2.1.51729: tcp 0
    


  • @johnpoz I'll install wireshark and have a look, it looks like it's trying to connect to the webpage in the browser, but never gets there.



  • @johnpoz Could DNS be causing issues here? I don't think I have it setup correctly.


  • LAYER 8 Global Moderator

    @johnpoz said in OpenVPN client can ping but not access server on LAN:

    12:53:08.909830 IP 192.168.2.10.85 > 192.168.2.1.63368: tcp 1440
    12:53:09.143689 IP 192.168.2.10.85 > 192.168.2.1.37840: tcp 0
    12:53:09.170709 IP 192.168.2.10.85 > 192.168.2.1.51729: tcp 0

    2.10 is serving up the webpage right? And 10.2 is the client trying to view the webpage.

    You clearly are getting there, and your seeing answers.. But what are the answers... Pfsense has no control over the answers.. It just forwards the packets back and forth between the client and the server.. It has no interest or influence over what those answers might be.



  • @johnpoz That's correct. I can get it fine by going through the net with standard port forwarding, just this VPN stuff is causing problems.


  • LAYER 8 Global Moderator

    To pfsense there is NO difference.. Pfsense doesn't care if what interface you come in on, be it a vpn interface or wan interface..

    You have something else going on..

    You can clearly see pfsense doing what it was told, send traffic to dest IP on port X, and then return whatever is returned to who asked for it, if there is an answer - no matter what that answer might be.



  • @johnpoz This is from wireshark. I've not used it before so not sure what I'm looking at.

    wire.PNG .


  • LAYER 8 Global Moderator

    This is 10.2 telling 2.10 to F off with this connection.. The RST is a reset for this connection

    RST.png

    This is 10.2 asking 2.10 for something that get http 1.1

    2.10 answers.. But then your 10.2 looks be trying to find c-ring.msedge.net from 192.168.1.1, and 192.168.1.1 telling him sorry no REFUSED.

    this.png

    If your wanting your vpn clients to use pfsense (unbound) for dns, you have to add your vpn tunnel network to the ACLs on unbound.. Or yeah it will refuse any connections.

    I take it this some ring camera? And looks like your client 10.2 needs to talk to ring to finish the connection??

    acls.png

    Out of the box unbound allows queries from networks pfsense is directly attached too.. But tunnel networks do not get access automatically.. You have to allow them via ACL.

    edit: I do not have ring anything to play with... But you sure you can use ring without internet access.

    I would test by putting say 2 devices on your opt network. Where neither actually have internet access and try and access your ring device.. Its possible some sort of auth or something has to happen via the internet??



  • @johnpoz It's for a Swann network security system.

    I'm assuming I don't need DNS for this VPN at all since I'm purely using IP addresses. I might remove the DNS servers from the OpenVPN config.

    I'm pretty sure it'll work offline as I can connect to it via a simple NAT port forward and still no gateway.



  • @johnpoz This is from wireshark after I removed DNS from the OpenVPN server config and re-exported it to the client

    wire.PNG


  • LAYER 8 Global Moderator

    @Andy142 said in OpenVPN client can ping but not access server on LAN:

    I'm pretty sure it'll work offline as I can connect to it via a simple NAT port forward and still no gateway.

    Sorry not possible.. Unless your talking about after you put in the source nat..

    You can not talk to something from another network, be it vpn or internet without what your talking to having a gateway.. Unless you do source natting.. Just not possible!

    Your showing bits and pieces of a sniff... In that last one your showing a connection closing with Fin,Ack.. from 2.10 to 10.2 - that is your securing telling 10.2 I don't want to talk any more.

    How are you testing this port forward you - actually from the OUTSIDE, ie the internet.

    Also looks like you might have lost vpn connection there, or that sure isn't just your internet connection? Since seeing arp for pfsense 10.1 looking for your client? 10.2



  • @johnpoz When I setup a NAT like in the picture below, and use my WAN IP to connect, it works just fine (so long as I have port 9000 as well).

    port.PNG

    OPT1 still doesn't have a gateway set.

    I am running on a slow latent connection, but it's still fast enough to run youtube low quality.


  • LAYER 8 Global Moderator

    @Andy142 said in OpenVPN client can ping but not access server on LAN:

    and use my WAN IP to connect,

    From where??? If your on the same network and using nat reflection.

    Let me state this again... You can not talk to a device from a different network, without that device knowing how to answer you... Its just not possible!! Period!

    So either this device needs a gateway to send traffic that is not local to its network, or its needs route specific to know where to send traffic for specific networks that might be talking to it.

    Without the client having a gateway or a specific route it is IMPOSSIBLE to talk to it from another network.. Period!!

    Unless you source nat/proxy the connection so that the device your talking to thinks the traffic is local to its network, and can send the traffic back to the source natted IP or proxy that is on its local network..

    OPT1 still doesn't have a gateway set.

    Opt1 would never have a gateway set, its a local interface of pfsense... When you say gateway - it means the devices on opt1 pointing back to pfsense as their gateway..

    Out of the box if a client on this opt1 network gets dhcp from pfsense, it would be handed a gateway of the pfsense opt1 IP.. So yes your device on your opt1 network would have a gateway (pfsense)

    Do you have gateway set on your pfsense lan interface? If so then its WRONG!! The only interface on pfsense that would have gateways are your wan connection(s).. This is how pfsense knows how to answer traffic from the internet..



  • @johnpoz I'm pretty lost now. I'm currently out of the country and using a VPN to get back into Australia.

    I was thinking that my OPT1 interface didn't have access to the internet because it didn't have a gateway set, but now I realise that's wrong.

    I'm also confused how I can connect to the security system with basic port forwarding to the Security system, but when I VPN into the LAN, I can only ping and not access the webpage.


  • LAYER 8 Global Moderator

    I don't know the ins and out of how this security device works. But clearly it has a gateway (pfsense). And there is no reason to do the source natting of your vpn connection.

    From what you have shown the device is answering.. But was showing RST from your client, and Fin,ack from your device to your clients.. Both are ways to END a conversation.

    So what is actually the issue with vpn vs internet not sure? But from what you have shown pfsense is doing what its told to correctly.

    I would suggest you sniff on pfsense opt1 interface for your device IP. Set the sniffing packets limit from 100 to 0 so you can see the full conversation... Then start a conversation from internet doing your normal forwarding..

    So you can see what is all involved with normal working conversation. Then make sure you kill any states for this conversation.. Reboot the device say, and then doing the same sniffing and talking from your vpn client.. So you can see what might be different?

    Off the top of head, thing that might be different while your on the actual internet with your client doing port forwarding on pfsense is you have access to internet from your client via the same connection. While your vpn connection would change that sort of connection, etc.

    Its possible your device phones home and checks something before allowing connection? It could be all kinds of things. But from what you have shown pfsense is doing exactly what it should be doing, and again doesn't care if your coming from the internet or a vpn.. It just allows the traffic or it doesn't..


Log in to reply