Unable to connect to WAN when connecting from Client to OpenVPN server.
-
What I am trying to achieve is to use the VPN client on a Windows laptop (OS windows 10) to connect to the OpenVPN server which is running on a pfsense firewall version 2.4.5.
Once connected to the OpenVPN server I want the client to redirect all connections to the WAN through the OpenVPN server.
So far the Client can connect is given an IP from the OpenVPN server but is unable to connect to the internet.
There are two things I find odd when I connect with the client I am not given a default gateway in the IPconfig on the client for the VPNtunnel - possibly this is expected behaviour or not?
And no traffic is routed back through the Tunnel
Configuration from the GUI is as follows:
OpenVPN config
I think that should show the way it is configured... I am no doubt sure that there is something wrong with the config - yet this has never worked.
There has never been any issues connecting with the clients to the OpenVPN server.
It is how the traffic is routed, or the lack of routing once the client is attached to the Tunnel. The rules I pushed was to try to give the client a helping hand...possibly not a good choice...
If you can see any potential misconfiguration which is causing the traffic not to route properly would be appreciated.
Many Tnx.
-
@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:
There are two things I find odd when I connect with the client I am not given a default gateway in the IPconfig on the client for the VPNtunnel - possibly this is expected behaviour or not?
Yes, that is as expected. OpenVPN does not set a real default gateway, instead it adds two routes for 0.0.0.0/1 and 128.0.0.0/1, which also covers the whole IPv4 range.
Your firewall rule on OPT1 only allows TCP traffic. You will also need UDP for DNS resolution.
You did not show the OpenVPN rule tab. So subject to that the rule on OPT1 should be the only real showstopper as far as I can see.However, there are some additional miss-configurations in your setup:
The outbound NAT rules on OPT1 are useless, since you don't need connections to go out this interface. You only have incoming connections there.
Furthermore, also OPT1 by itself is not needed in your setup, but should not be a drawback if you have it.
Consider, if you remove it, to move the firewall rules to OpenVPN tab.The port forwarding on OpenVPN seems useless for me and won't work anyway. No idea what you want to achieve with that.
The gateway option in the rule on OPT1 is also not necessary, since WAN GW is presumably the default gateway anyway.
OpenVPN server:
The domain name you provided as default domain is really your local domain?As already mentioned, the push route options you entered in the advanced options are unnecessary, since the server pushes already the default route. Possibly that's an obstruction actually.
-
Tnx for the suggestions I have removed all the unnecessary NAT rules for OPT1 and as suggested even removed this interface.
I have removed the routes I was pushing in the advanced config on OpenVPN
And here are the rules on the OpenVPN tab also changed to allow both UDP and TCP
As far as I can see it is wide open so I don't understand why this would not be allowing traffic.
To me it looks wide open and we will have to close things down - but first we need the basics to work....
OpenVPN server:
The domain name you provided as default domain is really your local domain?We have no local domain no servers on the LAN behind the pfsense we want to use this purely for the OpenVPN tunnel - so the LAN interface is pretty much redundant to us....
-
@ianh
Is the outbound NAT rule for the OpenVPN tunnel network still in place?Does the client connect without issues? Something in the log on client or server?
Show the clients routing table.
Try to ping 8.8.8.8 from the client.
-
This is the outbound rule for OpenVPN tunnel
This is the log from the client the connection shows no errors and this is the routing table:
2021-01-06 12:07:41 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2021-01-06 12:07:41 Windows version 10.0 (Windows 10 or greater) 64bit
2021-01-06 12:07:41 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10
Enter Management Password:
2021-01-06 12:07:48 TCP/UDP: Preserving recently used remote address: [AF_INET]95.154.192.200:1194
2021-01-06 12:07:48 UDPv4 link local (bound): [AF_INET][undef]:1194
2021-01-06 12:07:48 UDPv4 link remote: [AF_INET]95.154.192.200:1194
2021-01-06 12:07:48 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-01-06 12:07:49 [mercury.paac-it.com] Peer Connection Initiated with [AF_INET]95.154.192.200:1194
2021-01-06 12:07:50 open_tun
2021-01-06 12:07:50 tap-windows6 device [OpenVPN TAP-Windows6] opened
2021-01-06 12:07:50 Set TAP-Windows TUN subnet mode network/local/netmask = 10.3.200.0/10.3.200.2/255.255.255.0 [SUCCEEDED]
2021-01-06 12:07:50 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.3.200.2/255.255.255.0 on interface {A2C4D3E6-3922-4706-8943-83589ECC4E95} [DHCP-serv: 10.3.200.254, lease-time: 31536000]
2021-01-06 12:07:50 Successful ARP Flush on interface [17] {A2C4D3E6-3922-4706-8943-83589ECC4E95}
2021-01-06 12:07:50 IPv4 MTU set to 1500 on interface 17 using service
2021-01-06 12:07:55 Initialization Sequence CompletedC:\Users\IanHarwood>route print
Interface List
7...1c 1a df b0 ed 33 ......Surface Ethernet Adapter
5...........................Wintun Userspace Tunnel
17...00 ff a2 c4 d3 e6 ......TAP-Windows Adapter V9
19...04 33 c2 10 6e 91 ......Microsoft Wi-Fi Direct Virtual Adapter
9...06 33 c2 10 6e 90 ......Microsoft Wi-Fi Direct Virtual Adapter #2
10...04 33 c2 10 6e 90 ......Intel(R) Wi-Fi 6 AX201 160MHz
1...........................Software Loopback Interface 1IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.33 45
0.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
10.3.200.0 255.255.255.0 On-link 10.3.200.2 281
10.3.200.2 255.255.255.255 On-link 10.3.200.2 281
10.3.200.255 255.255.255.255 On-link 10.3.200.2 281
95.154.192.200 255.255.255.255 192.168.0.1 192.168.0.33 301
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
128.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
192.168.0.0 255.255.255.0 On-link 192.168.0.33 301
192.168.0.33 255.255.255.255 On-link 192.168.0.33 301
192.168.0.255 255.255.255.255 On-link 192.168.0.33 301
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.3.200.2 281
224.0.0.0 240.0.0.0 On-link 192.168.0.33 301
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.3.200.2 281
255.255.255.255 255.255.255.255 On-link 192.168.0.33 301Persistent Routes:
NoneIPv6 Route Table
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
17 281 fe80::/64 On-link
10 301 fe80::/64 On-link
17 281 fe80::b05d:3a66:e901:c2f0/128
On-link
10 301 fe80::bd3d:8014:35bb:a3c2/128
On-link
1 331 ff00::/8 On-link
17 281 ff00::/8 On-link
10 301 ff00::/8 On-linkPersistent Routes:
NoneC:\Users\IanHarwood>tracert 8.8.8.8
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:1 24 ms 21 ms 24 ms 10.3.200.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 ^C
C:\Users\IanHarwood>There are many errors in the pfsense but it seems that these are generic errors and not related to my issue - based on previous searches in google etc...
There were error(s) loading the rules: /tmp/rules.debug:143: unknown protocol udp4 - The line in question reads [143]: pass in quick on $WAN reply-to ( vtnet0 95.154.192.1 ) inet proto udp4 from any to 95.154.192.200 tracker 1608329661 keep state label "USER_RULE: OpenVPN Remote Technical Staff wizard"
-
results from ping test
C:\Users\IanHarwood>ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), -
@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:
This is the outbound rule for OpenVPN tunnel
Dude, you need an outbound NAT rule for the source of the OpenVPN tunnel network on the WAN interface!
I mentioned that already. Also that the outbound NAT on the VPN interface is useless in your case!Outbound NAT is to be set on interfaces where the traffic is going out!
The vpn clients traffic is coming in on the OpenVPN interface and is going out on WAN. For getting responses back to the WAN IP, the source address in the outgoing packets has to be translated into the interface address. That is the job of the outbound NAT. -
I am sorry I misunderstood your previous comment, as this NAT rule seem to be vital for this working can you give me some guidance as to how this should be configured?
You mention the following:
For getting responses back to the WAN IP, the source address in the outgoing packets has to be translated into the interface address. That is the job of the outbound NAT.
With this in mind I have configuered the NAT rule as follows:
What should I put for the interface?
With this configuration still the traffic does not route and as far as I can tell the Routing table does not change on the client:
IPv4 Route Table
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.33 45
0.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
10.3.200.0 255.255.255.0 On-link 10.3.200.2 281
10.3.200.2 255.255.255.255 On-link 10.3.200.2 281
10.3.200.255 255.255.255.255 On-link 10.3.200.2 281
95.154.192.200 255.255.255.255 192.168.0.1 192.168.0.33 301
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
128.0.0.0 128.0.0.0 10.3.200.1 10.3.200.2 281
192.168.0.0 255.255.255.0 On-link 192.168.0.33 301
192.168.0.33 255.255.255.255 On-link 192.168.0.33 301
192.168.0.255 255.255.255.255 On-link 192.168.0.33 301
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.3.200.2 281
224.0.0.0 240.0.0.0 On-link 192.168.0.33 301
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.3.200.2 281
255.255.255.255 255.255.255.255 On-link 192.168.0.33 301Persistent Routes:
NoneTnx.
-
@ianh
The NAT rule is okay now. Ensure that the Outbound NAT is working in hybrid or manual mode.If you have no love anyway, you have to do some troubleshooting. You the packet capture tool on pfSense to sniff the traffic on the respective interfaces.
Select the WAN interface and ICMP protocol and enter 8.8.8.8 at host, then start the capture and try a ping on the client to 8.8.8.8. Stop it and check the result.
If there is nothing switch to the OpenVPN interface and try again.
Post the results, please. -
I have taken the packet capture and do not see anything in particular in wireshark other than:
This is for the WAN inteface
4 14.587045 10.3.200.2 8.8.8.8 ICMP 74 Echo (ping) request id=0x0001, seq=36/9216, ttl=127 (no response found!)
Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 6, 2021 14:19:46.475145000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1609942786.475145000 seconds
[Time delta from previous captured frame: 5.002190000 seconds]
[Time delta from previous displayed frame: 5.002190000 seconds]
[Time since reference or first frame: 14.587045000 seconds]
Frame Number: 4
Frame Length: 74 bytes (592 bits)
Capture Length: 74 bytes (592 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Xensourc_81:51:b7 (00:16:3e:81:51:b7), Dst: Cisco_d1:a3:e9 (00:62:ec:d1:a3:e9)
Destination: Cisco_d1:a3:e9 (00:62:ec:d1:a3:e9)
Source: Xensourc_81:51:b7 (00:16:3e:81:51:b7)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.3.200.2, Dst: 8.8.8.8
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 60
Identification: 0xb498 (46232)
Flags: 0x00
Fragment Offset: 0
Time to Live: 127
Protocol: ICMP (1)
Header Checksum: 0xa513 [validation disabled]
[Header checksum status: Unverified]
Source Address: 10.3.200.2
Destination Address: 8.8.8.8
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4d37 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence Number (BE): 36 (0x0024)
Sequence Number (LE): 9216 (0x2400)
[No response seen]
Data (32 bytes)This is for the OpenVPN interface
1 0.000000 10.3.200.2 8.8.8.8 ICMP 64 Echo (ping) request id=0x0001, seq=39/9984, ttl=128 (no response found!)
Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits)
Encapsulation type: NULL/Loopback (15)
Arrival Time: Jan 6, 2021 14:23:05.964157000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1609942985.964157000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: null:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Null/Loopback
Internet Protocol Version 4, Src: 10.3.200.2, Dst: 8.8.8.8
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 60
Identification: 0x2852 (10322)
Flags: 0x00
Fragment Offset: 0
Time to Live: 128
Protocol: ICMP (1)
Header Checksum: 0x305a [validation disabled]
[Header checksum status: Unverified]
Source Address: 10.3.200.2
Destination Address: 8.8.8.8
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4d34 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence Number (BE): 39 (0x0027)
Sequence Number (LE): 9984 (0x2700)
[No response seen]
Data (32 bytes)Tnx.
-
@ianh
What is this??
I was asking for the simple capture result with default options! -
@viragomann it is the result with default options.
I tried to upload to the forum but it would not accept the .cap files.
So I opened in wireshark and copied the results here...
Not sure how else you want me to display this?
-
@viragomann looks like its being run under virtualization, check the MAC address.
-
@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:
Not sure how else you want me to display this?
Simply copy and paste the result here. Enclose it in a code frame for readability.
-
@viragomann Tnx for your help in trying to get this sorted. There was an additional layer to this problem which was as @NogBadTheBad stated the pfsense server is a VM.
Long story short once we had rolled out a new OPENvpn server and chosen Automated NAT rules the connection is working and as we wanted all traffic is being routed via the VPN tunnel :)
Unknown adapter OpenVPN TAP-Windows6:
Connection-specific DNS Suffix . : paacvpn
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-A3-2E-4B-10
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::419:140e:1684:a44b%17(Preferred)
IPv4 Address. . . . . . . . . . . : 10.3.200.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 15 January 2021 16:43:21
Lease Expires . . . . . . . . . . : 15 January 2022 16:43:21
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 10.3.200.254
DHCPv6 IAID . . . . . . . . . . . : 285278115
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-27-52-C3-D6-1C-1A-DF-B0-ED-33
DNS Servers . . . . . . . . . . . : 8.8.8.8
8.8.4.4
1.1.1.1
NetBIOS over Tcpip. . . . . . . . : EnabledC:\WINDOWS\system32>ping google.com
Pinging google.com [216.58.198.174] with 32 bytes of data:
Reply from 216.58.198.174: bytes=32 time=25ms TTL=117
Reply from 216.58.198.174: bytes=32 time=24ms TTL=117
Reply from 216.58.198.174: bytes=32 time=27ms TTL=117
Reply from 216.58.198.174: bytes=32 time=25ms TTL=117Ping statistics for 216.58.198.174:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 27ms, Average = 25msC:\WINDOWS\system32>tracert google.com
Tracing route to google.com [216.58.198.174]
over a maximum of 30 hops:1 25 ms 24 ms 26 ms 10.3.200.1
2 22 ms * 24 ms 95.154.192.1
3 25 ms 23 ms 26 ms 109.169.17.190
4 25 ms 24 ms 22 ms po201.net2.north.dc5.as20860.net [84.22.173.154]
5 26 ms 24 ms 23 ms be256.asr02.dc5.as20860.net [130.180.203.7]
6 40 ms 25 ms 22 ms be256.asr01.ld5.as20860.net [130.180.202.46]
7 26 ms 25 ms 24 ms 72.14.219.214
8 24 ms 24 ms 24 ms 108.170.246.129
9 38 ms 34 ms 23 ms 108.170.232.97
10 25 ms 23 ms 25 ms lhr25s10-in-f14.1e100.net [216.58.198.174]Trace complete.
So thanks for your patience in trying to guide me to a solution.
All the best!
