OpenVPN client can ping but not access server on LAN
-
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 40For 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 40It doesn't look like the NAT is doing anything?
-
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.
-
@Andy142 , Can I see a screenshot of your Mappings?
Go to Firewall > NAT > Outbound -
Sure thing, here you go.
-
@Andy142 , Do you how to make Aliases?
-
@AKEGEC Not really... Sorry
-
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 40The 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 40Looks like it's replying to the default gateway now at least.
-
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"?
-
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....
-
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 870The 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 0Looks like everything should be working....
-
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.