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


  • Hello,

    I am very new to pfsense firewall and OpenVPN and doing my best to set up a solution where we can log in to the OpenVPN server get allocated an IP to then be able to log in remotely to managed servers etc for Management Purposes such as ssh to a webserver from a fixed IP range etc.

    Current issue is that when logged in via the client no traffic seems to get rooted back through the VPN tunnel even though the Force all clients option is set.

    I have noticed that when connected (windows 10 pro os) I am not assigned any Gateway:

    Unknown adapter OpenVPN TAP-Windows6:

    Connection-specific DNS Suffix . : xxxxxxx
    Description . . . . . . . . . . . : TAP-Windows Adapter V9
    Physical Address. . . . . . . . . : xxxxxxxxxxxxxxxxx
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes

    IPv4 Address. . . . . . . . . . . : 123.45.5.2(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Lease Obtained. . . . . . . . . . : 24 December 2020 13:20:18
    Lease Expires . . . . . . . . . . : 24 December 2021 13:20:18
    Default Gateway . . . . . . . . . :
    DHCP Server . . . . . . . . . . . : 123.45.5.254

    Network Config on pfsense

    [2.4.5-RELEASE][root@Mercury.paac-it.com]/root: ifconfig
    vtnet0:
    inet <external IP> netmask 0xffffff00 broadcast <external IP>
    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

    vtnet0.1001: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 150 0
    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 123.45.1.1 netmask 0xffff0000 broadcast 123.45.255.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 123.45.5.1 --> 123.45.5.2 netmask 0xffffff00
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: tun openvpn
    Opened by PID 56860

    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

    I choose the 123 range due to this log entry:

    block anything from private networks on interfaces with the option set

    block in log quick on $LAN from 10.0.0.0/8 to any tracker 12000 label "Block private networks from LAN block 10/8"

    Originally we used the same as in the documentation explanation 10.3.201.0/24 for VPN and the Lan was in the 10.3.0.1/24

    However given that it seems that we have routing issues I thought I would try to help this allong by putting the VPN in the same subnet as the LAN - if my understanding is correct.
    The only thing we want to do with the OpenVPN is get clients to connect to this Server and then connect back out to the WAN using this tunnel we have no need for connection to Private LAN's etc.

    I have looked at the following options with regards to firewall rules:
    As for instance from the pfsense firewall I have no issues pinging 8.8.4.4 however from the client this is not possible and clearly it does not understand how to route its traffic there:

    I believe there is an error in how we have the routing setup between the OpenVPN and the pfsense firewall - just cannot identify where.

    ff617827-e7eb-4aa2-be2b-1544f21f687f-image.png

    d380228a-8271-44b0-a34e-533983c1811c-image.png

    52a1549d-efab-4f9d-b4bc-c1564f61c816-image.png

    So basically everything is open as far as I can see - no fancy or difficult rules.

    We have also added these persistent routes:

    2579744b-b299-448f-9f35-4868b71ca569-image.png

    This is the config File on the Client:

    dev tun
    persist-tun
    persist-key
    data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
    data-ciphers-fallback AES-256-CBC
    auth SHA1
    tls-client
    client
    resolv-retry infinite
    remote 95.154.192.200 1194 udp4
    verify-x509-name "mercury.xxxx name
    auth-user-pass
    pkcs12 Mercury-UDP4-1194-ian.harwood.p12
    tls-auth Mercury-UDP4-1194-ian.harwood-tls.key 1
    remote-cert-tls server

    This is the routes I get when I am connected:

    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 40
    0.0.0.0 128.0.0.0 123.45.5.1 123.45.5.2 281
    95.154.192.198 255.255.255.255 123.45.5.1 123.45.5.2 281
    <external ip> 255.255.255.255 192.168.0.1 192.168.0.33 296
    123.45.5.0 255.255.255.0 On-link 123.45.5.2 281
    123.45.5.2 255.255.255.255 On-link 123.45.5.2 281
    123.45.5.255 255.255.255.255 On-link 123.45.5.2 281
    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 123.45.5.1 123.45.5.2 281
    192.168.0.0 255.255.255.0 On-link 192.168.0.33 296
    192.168.0.33 255.255.255.255 On-link 192.168.0.33 296
    192.168.0.255 255.255.255.255 On-link 192.168.0.33 296
    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 123.45.5.2 281
    224.0.0.0 240.0.0.0 On-link 192.168.0.33 296
    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 123.45.5.2 281
    255.255.255.255 255.255.255.255 On-link 192.168.0.33 296

    From the Client when connected to VPN I can ping the LAN the LAN gateway the VPN Gateway and the External IP of the VPN server.

    Any other traffic is not reachable - so must be the way we have the internal routing set up and I am still stumped why we do not receive a "Gateway" configuration on the Client when connected to OpenVPN.

    If anyone can give me some pointers I would appreciate it as I have spent hours racking my brains and reading manuals -

    I have found mentions of these commands in various forums - however I would like to understand how you configure this properly instead of just adding this to config files, and not sure if this will address the issue I am having:

    *1. Redirect all the traffic into the tunnel

    The easiest solution - use OpenVPN's --redirect-gateway autolocal option (or put it in the config file as redirect-gateway autolocal.*

    However this option is configured in the OpenVPN Server Config.

    *a. Enable packet forwarding

    By default in most distributions the packet forwarding is disabled, hence packets from the tunnel interface never make it to the public interface. You must enable forwarding with:

    ~ # sysctl net.ipv4.ip_forward=1
    net.ipv4.ip_forward = 1*

    Not sure where to make this change and if its relevant, as we have done the config in the GUI so far.

    Also seen something about IPTABLES - but this is not a recognised command in the pfsense console, and I believe this is already enabled in a Firewall rules?

    ~ # iptables -I FORWARD -j ACCEPT

    we did receive advice from another forum - but this is configured allready:

    You need to go into the openVPN settings in pfSense and tell it to set the default gateway on clients.

    In the "Tunnel settings", there should be an option "redirect Gateway", this needs to be set, in order for the external traffic to be forced through the VPN tunnel.

    Any help greatly received.

    Tnx :)


  • This post is deleted!

  • Just appended this Route as I noticed I had put in a wrong IP in the push command from the OpenVPN config. SO I can confirm that when I Push two routes to the Clients these are configured as so:

    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 123.45.5.1 123.45.5.2 281
    95.154.192.198 255.255.255.255 123.45.5.1 123.45.5.2 281
    109.169.81.215 255.255.255.255 123.45.5.1 123.45.5.2 281

    So I think the problem we are having is how to route traffic from the VPN network with gateway 123.45.5.1 to the WAN.

    I am trying to work out where is the misconfig that is blocking this....


  • 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


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


  • @viragomann

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

    ;) too much x-mas drinks ;)


  • @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. ๐Ÿ˜‰


  • @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!


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


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


  • @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:โŒxโŒx%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


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


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


  • @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:

    cd6d3f47-2f6e-4c29-82b7-402cefb9452c-image.png

    8b26a98f-245d-4e1b-b1a2-cb2818ecef5f-image.png

    8d83ba7b-aba5-4c5a-9331-6e2c5424008f-image.png

    e30334e3-6af6-49e8-aaa0-b9c34cc49f02-image.png

    90d8f7b6-4349-40b3-ad5c-09ee99902af1-image.png

    dfbeaa8a-c1ab-456c-b2e3-26e84face804-image.png

    OpenVPN config

    369c8ea8-600e-4c8e-b3f0-42de76bc816a-image.png

    b7773fb2-e5b3-4a24-b908-23787145d593-image.png

    4c7a9378-57ed-4b15-a318-54aef3acbd07-image.png

    4deb2010-14e0-4cca-977c-309a61e21524-image.png

    a375a8b0-d28f-43b4-946b-906a1be9ced0-image.png

    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.


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

    e181a4b3-99ba-44e9-b165-6dcc75cf9b02-image.png

    2ea012db-3b58-4899-9823-1ced9144ee02-image.png

    0687ad19-d82a-4003-9881-164a068e15a8-image.png

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

    d64751d6-6230-4207-90e9-0992a5b72f77-image.png

    641b1740-22c0-49d2-8665-4f1dd6f6e68e-image.png

    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.


  • @viragomann

    This is the outbound rule for OpenVPN tunnel

    2f49f316-9e29-40a8-a9c1-e5d4e4e71797-image.png

    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"


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


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


  • @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:

    1de5c146-e09a-432f-93d0-6db786a5e9e0-image.png

    What should I put for the interface?

    86c84955-c09a-4489-b224-1956cc316455-image.png

    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.


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


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


  • @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?

  • Galactic Empire

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

    C:\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=117

    Ping 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 = 25ms

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