Unable to connect to WAN when connecting from Client to OpenVPN server.

[noplan]

A) Your openVpn server is pfS?
B) your client can connect via openVpn to the openVpn server on pfS?
C) the connected clients get their ip dns etc?
D) you run Splitt tunnel (DNS or not)
E) connect to win machines (netBios) planned
F) your NAT settings on pfS (hybrid???)
G) your servers / you want to reach when dialed in via openVpn on LAN interface or on optX?

Next steps after answer.
BrNP

[viragomann]

@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:

We have a simple setup with a pfsense firewall with one WAN adapter
We have created a LAN with ip range 123.45.1.0/16
We have created a VPN tunnel with 123.45.5.0/24

These networks are overlapping. So there is no routing possible between them.

[noplan]

@viragomann

oh boy yes true i thougth this was just an example like 123456 then i stoped readin ;)

;) too much x-mas drinks ;)

[viragomann]

@noplan
So did I, cause public IP ranges should not be used for private networks. But even if its an example IP, it's a bad one.

[ianh]

@noplan

Thanks for your comments so far - and point noted about my IP allocation - as this was testing I was not being so pedantic about it - but I have changed these now.

TO answer your questions:

A) Your openVpn server is pfS?
Yes 2.4.5-RELEASE-p1 (amd64)

B) your client can connect via openVpn to the openVpn server on pfS?
Yes they connect on Public IP to pfs

C) the connected clients get their ip dns etc?
The Connected Clients get the following config:

Connection-specific DNS Suffix . : paacvpn
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-A2-C4-D3-E6
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::b05d:3a66:e901:c2f0%17(Preferred)
IPv4 Address. . . . . . . . . . . : 10.3.200.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 26 December 2020 10:30:57
Lease Expires . . . . . . . . . . : 26 December 2021 10:30:57
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 10.3.200.254
DHCPv6 IAID . . . . . . . . . . . : 721485730
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. . . . . . . . : Enabled

D) you run Splitt tunnel (DNS or not)
No everything is tunnelled selected in the GUI and this is the config on the client:
dev tun
persist-tun

E) connect to win machines (netBios) planned - elaborate on this question if you will?

F) your NAT settings on pfS (hybrid???)

Based on another article I found I did have Automatic but changed this to manual and then copied and added NAT rules for the WAN to use the OPT1 interface, as explained here: pfsense-with-expressvpn-openvpn

G) your servers / you want to reach when dialed in via openVpn on LAN interface or on optX?

We want to go back out to the WAN via the OPT1 interface.

I have changed the LAN to 10.3.0.0/24 and OPT1 10.3.201.0/24 - as it was before when it still was not working.

If you need any more info from me please let me know. I have shell access if you need me to run commands and show outputs etc.

Many Tnx!

[viragomann]

@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:

F) your NAT settings on pfS (hybrid???)
Based on another article I found I did have Automatic but changed this to manual and then copied and added NAT rules for the WAN to use the OPT1 interface, as explained here: pfsense-with-expressvpn-openvpn

ExpressVPN is a VPN provider. So that guide describes the setup to connect to a VPN provider and route the upstream traffic to it. That is not what you want.
In your case you do the part of the vpn provider for clients that connect to your server. So you have to route out their upstream traffic to the WAN gateway.

So you need an outbound NAT rule for the source range of the vpn tunnel network on the WAN interface.

If that does not work, again show your setup configuration. After you've obviously changed several things already:
OpenVPN server settings
interface settings
firewall rules
outbound NAT rules

[ianh]

@viragomann

Yes definitely made some changes but still cannot get the basic config to work.

Just to check what I am trying to do should be plausible right?

Use the OpenVPN to tunnel all traffic through it for management purposes?

Current set up is as follows I have managed to pull the information from the shell as I figure it might be easier than looking at screenshots.. if you want me to add screenshots I will:

Open VPN server settings are as follows:

dev ovpns1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local pfsense IP
tls-server
server 10.3.200.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server1
username-as-common-name
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'xxxxxxxxx' 1"
lport 1194
management /var/etc/openvpn/server1.sock unix
push "dhcp-option DOMAIN paacvpn"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "dhcp-option DNS 1.1.1.1"
push "redirect-gateway def1"
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server1.tls-auth 0
ncp-disable
persist-remote-ip
float
topology subnet
push "route x.x.x.215 255.255.255.255"

push "route x.x.x.198 255.255.255.255"

The x.x.x is just not to reveal the public IP of the routes I am pushing.

[ianh]

@viragomann

interface settings:
interface settings:

vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6d00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:16:3e:81:51:b7
hwaddr 00:16:3e:81:51:b7
inet6 x:xx%vtnet0 prefixlen 64 scopeid 0x1
inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T <full-duplex>
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
enc0: flags=0<> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
pflog0: flags=100<PROMISC> metric 0 mtu 33160
groups: pflog
vtnet0.1001: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:16:3e:81:51:b7
inet6 fe80::216:3eff:fe81:51b7%vtnet0.1001 prefixlen 64 scopeid 0x6
inet 10.3.0.1 netmask 0xffffff00 broadcast 10.3.0.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T <full-duplex>
status: active
vlan: 1001 vlanpcp: 0 parent interface: vtnet0
groups: vlan
ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet6 fe80::216:3eff:fe81:51b7%ovpns1 prefixlen 64 scopeid 0x7
inet 10.3.200.1 --> 10.3.200.2 netmask 0xffffff00
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: tun openvpn
Opened by PID 85977

[ianh]

@viragomann
Firewall and NAT rules

/var/etc/openvpn: cat /tmp/rules.debug

loopback = "{ lo0 }"
WAN = "{ vtnet0 }"
LAN = "{ vtnet0.1001 }"
OPT1 = "{ ovpns1 }"
OpenVPN = "{ openvpn }"

User Aliases

Gateways

GWGW_WAN = " route-to ( vtnet0 95.154.192.1 ) "
GWOPT1_VPNV4 = " route-to ( ovpns1 10.3.200.1 ) "

set loginterface vtnet0.1001

set skip on pfsync0

scrub on $WAN all fragment reassemble
scrub on $LAN all fragment reassemble
scrub on $OPT1 all fragment reassemble

no nat proto carp
no rdr proto carp
nat-anchor "natearly/"
nat-anchor "natrules/"

Outbound NAT rules (manual)

nat on $WAN inet from 127.0.0.0/8 to any port 500 -> pfsense IP static-port # Auto created rule for ISAKMP - localhost to WAN
nat on $OPT1 inet from 127.0.0.0/8 to any port 500 -> 10.3.200.1/32 static-port # Auto created rule for ISAKMP - localhost to WAN
nat on $WAN inet from 127.0.0.0/8 to any -> pfsense IP port 1024:65535 # Auto created rule - localhost to WAN
nat on $OPT1 inet from 127.0.0.0/8 to any -> 10.3.200.1/32 port 1024:65535 # Auto created rule - localhost to WAN
nat on $WAN inet6 from ::1/128 to any port 500 -> (vtnet0) static-port # Auto created rule for ISAKMP - localhost to WAN
nat on $OPT1 inet6 from ::1/128 to any port 500 -> (ovpns1) static-port # Auto created rule for ISAKMP - localhost to WAN
nat on $WAN inet6 from ::1/128 to any -> (vtnet0) port 1024:65535 # Auto created rule - localhost to WAN
nat on $OPT1 inet6 from ::1/128 to any -> (ovpns1) port 1024:65535 # Auto created rule - localhost to WAN
nat on $WAN inet from 10.3.0.0/24 to any port 500 -> pfsense IP static-port # Auto created rule for ISAKMP - LAN to WAN
nat on $OPT1 inet from 10.3.0.0/24 to any port 500 -> 10.3.200.1/32 static-port # Auto created rule for ISAKMP - LAN to WAN
nat on $WAN inet from 10.3.0.0/24 to any -> pfsense IP port 1024:65535 # Auto created rule - LAN to WAN
nat on $OPT1 inet from 10.3.0.0/24 to any -> 10.3.200.1/32 port 1024:65535 # Auto created rule - LAN to WAN
nat on $WAN inet from 10.3.200.0/24 to any port 500 -> pfsense IP static-port # Auto created rule for ISAKMP - OpenVPN server to WAN
nat on $OPT1 inet from 10.3.200.0/24 to any port 500 -> 10.3.200.1/32 static-port # Auto created rule for ISAKMP - OpenVPN server to WAN
nat on $WAN inet from 10.3.200.0/24 to any -> pfsense IP port 1024:65535 # Auto created rule - OpenVPN server to WAN
nat on $OPT1 inet from 10.3.200.0/24 to any -> 10.3.200.1/32 port 1024:65535 # Auto created rule - OpenVPN server to WAN

Load balancing anchor

rdr-anchor "relayd/*"

TFTP proxy

rdr-anchor "tftp-proxy/*"

NAT Inbound Redirects

rdr on openvpn proto { tcp udp } from 10.3.200.0/24 to 95.154.192.0/24 -> pfsense IP

UPnPd rdr anchor

rdr-anchor "miniupnpd"

anchor "relayd/"
anchor "openvpn/"
anchor "ipsec/*"

If you need anything else let me know.

Much appreciated.

[viragomann]

@ianh said in Unable to connect to WAN when connecting from Client to OpenVPN server.:

Yes definitely made some changes but still cannot get the basic config to work.

So what is the concrete problem now?

Just to check what I am trying to do should be plausible right?
Use the OpenVPN to tunnel all traffic through it for management purposes?

Not really clear, what you try to achieve. Once you write "route the whole client traffic over the vpn", then "for management purposes"(?).
Also in the config you have both settings, "push redirect gateway" and also "push special networks (IPs)". (?)

Current set up is as follows I have managed to pull the information from the shell as I figure it might be easier than looking at screenshots.

Since pfSense is configured via the web configurator, we are rather familiar with screenshots.

[ianh]

@viragomann

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.

[viragomann]

@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.

[ianh]

@viragomann

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....

[viragomann]

@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.

[ianh]

@viragomann

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 Completed

C:\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 1

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 301

Persistent Routes:
None

IPv6 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-link

Persistent Routes:
None

C:\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"

[ianh]

@viragomann

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),

[viragomann]

@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.

[ianh]

@viragomann

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 301

Persistent Routes:
None

Tnx.

[viragomann]

@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.

[ianh]

@viragomann

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.