Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing

    OpenVPN
    2
    17
    285
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jhg
      last edited by jhg

      I've configured an OpenVPN peer-to-peer between two pfSense boxes, and while the connection is established, routing between the networks isn't happening.

      • The connection is up according to the status page
      • The client pfSense can ping hosts on the server network
      • The server pfSense cannot ping hosts on the client network
      • Hosts (not the pfSense box) on one network cannot ping hosts on the other network
      • When attempting to ping from a client network host to a server network host, the server OpenVPN logs (level 4) contain errors like MULTI: bad source address from client [192.168.10.8], packet dropped, where the IP is on the client LAN
      • The routing tables on both ends look OK, see below (public IPs obfuscated)

      The tunnel network is 192.168.21.0/24

      SERVER SIDE (LAN net is 192.168.0.0/23)

      [2.7.2-RELEASE][admin@[server pfSense host]]/root: netstat -nr4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            207.225.84.48      UGS      pppoe1
[server public ip] link#4             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.0.0/23     link#2             U           re1
192.168.0.1        link#4             UHS         lo0
192.168.10.0/24    192.168.21.2       UGS      ovpns2
192.168.21.0/24    link#10            U        ovpns2
192.168.21.1       link#4             UHS         lo0
205.171.2.65       207.225.84.48      UGHS     pppoe1
205.171.3.65       207.225.84.48      UGHS     pppoe1
207.225.84.48      link#8             UH       pppoe1

      CLIENT SIDE (LAN net is 192.168.10.0/24)

      [2.7.2-RELEASE][admin@[client pfSense host]]/root: netstat -nr4
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            24.20.192.1        UGS         re1
24.20.192.0/22     link#2             U           re1
24.20.192.1        link#2             UHS         re1
[client public ip] link#4             UHS         lo0
96.108.64.181      24.20.192.1        UGHS        re1
127.0.0.1          link#4             UH          lo0
192.168.0.0/23     192.168.21.1       UGS      ovpnc1
192.168.10.0/24    link#1             U           re0
192.168.10.254     link#4             UHS         lo0
192.168.21.0/24    link#7             U        ovpnc1
192.168.21.2       link#4             UHS         lo0
192.168.100.0/22   link#2             U           re1
192.168.100.2      link#4             UHS         lo0

      I've double checked that the local and remote network specifications are correct at both ends.

      Questions:

      1. Where should I look next to troubleshoot this?
      2. I've read in a couple of places that peer-to-peer isn't well supported by OpenVPN. Should I switch to IPSec? Will that be easier?
      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @jhg
        last edited by

        @jhg
        I guess, you're missing the Client Specific Override on the server.

        J 1 Reply Last reply Reply Quote 0
        • J
          jhg @viragomann
          last edited by jhg

          @viragomann OK, I set up a client specific override and am now successfully connected.
          The only thing missing is DNS resolution, at the client LAN, of hosts in the server LAN.

          In the client-specific override I enabled the "DNS Default Domain" option and provided the server-side domain, as well as "Provide a DNS server list to clients" with the server-side DNS server IP.

          I tried adding a Domain Override to the client's DNS Resolver configuration for the server-side LAN and DNS server, but that just resulted in DNS resolution for server-side hosts timing out. I.e.

          • Without the override, dig <server-lan-host> immediately returns NXDOMAIN
          • With the override, the same command times out; dig <client-lan-host> returns correctly

          Suggestions?

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @jhg
            last edited by

            @jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

            In the client-specific override I enabled the "DNS Default Domain" option and provided the server-side domain, as well as "Provide a DNS server list to clients" with the server-side DNS server IP.

            I presume, that this setting is only applied to the client pfSense, but not to the client side DNS.

            I tried adding a Domain Override to the client's DNS Resolver configuration for the server-side LAN and DNS server, but that just resulted in DNS resolution for server-side hosts timing out. I.e.

            Without the override, dig <server-lan-host> immediately returns NXDOMAIN
With the override, the same command times out; dig <client-lan-host> returns correctly

            You might need a private domain entry in the Resolver custom options:

            server:
private-domain: "<DOMAIN>"

            Consider the append the domain, when resolving a host.

            J 1 Reply Last reply Reply Quote 0
            • J
              jhg @viragomann
              last edited by

              @viragomann Setting up peer-to-peer OpenVPN shouldn't be this difficult.

              One source of confusion is the use of "Client" for conflicting purposes. In the OpenVPN configuration UI "client" means that you are defining the client end of a peer-to-peer VPN, while Client Export is creating a file containing configuration data for clients that will connect TO this server. Those are two different meanings of "client".

              So that leaves "Client Specific Overrides". That seems to imply that it's something defined at the Server end to provide additional configuration to a connecting peer-to-peer client, and that's where I configured it.

              Is that not correct? Does the override belong at the client-side pfSense box?

              Also it's unclear why I need a Client Specific Override to provide the local and remote networks if they're already specified in the base client configuration. There's no additional data in the override that wasn't present in the initial client configuration, but somehow the override is required. That doesn't make much sense.

              @viragomann said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

              I presume, that this setting is only applied to the client pfSense, but not to the client side DNS.

              I'm not sure what you mean by this. The client pfSense is also the DNS resolver for the client-side LAN, but while the VPN is connected, from an ssh session on the client pfSense box. it is still not able to resolve server-side hostnames,. It seems the server isn't actually providing the DNS settings to the client that were given in the Client Specific Override.

              I'm at a loss here.

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @jhg
                last edited by

                @jhg
                The client export utility is meant to export config files and apps for access server clients.
                The server drop-down only shows access servers, not peer to peer servers.

                If you configure a peer to peer server you get a "Remote neworks" box in the setting, where you can enter client networks. This setting adds routes to pfSense pointing to the OpenVPN server (or maybe a client IP).
                However, pfSense is not able to route traffic to an client IP directly. It just can route packets to the OpenVPN server instance.

                You can connect multiple clients to a peer to peer server, however.
                In this case OpenVPN has to route the packets to the proper client. This is done by iroute inside OpenVPN.
                To set this properly, the CSO is required on the server and of course you have to state the respective client site networks here at "remote networks".

                This means, it is by design of OpenVPN.

                If you don't need multiple clients AND don't need DCO (OpenVPN Data Channel Offload) you can configure a /30 tunnel subnet and you can omit the CSO.

                The client pfSense is also the DNS resolver for the client-side LAN

                The DNS Resolver uses DNS root servers,as long as it's not in forwarding mode.

                Pushing a DNS server to a VPN client is like the ISP can push you a DNS via DHCP or like a DNS you've entered in System > General.
                These are applied to pfSense only by default. It is only used for DNS clients if you enable the Forwarding mode in DNS Resolver.
                If you want to use a DNS server at the remote site also ensure that the VPN interface is enable at outgoing interfaces.

                J 1 Reply Last reply Reply Quote 0
                • J
                  jhg @viragomann
                  last edited by

                  @viragomann I'm making progress.

                  Part of the issue was a missing firewall rule at the client allowing in traffic over the OpenVPN interface.

                  Now the problem reduces to DNS, with two issues.

                  • The client DNS resolver doesn't seem to know about the server side DNS. It never tries to resolve queries for server-side FQDNs even though the override provides the server-side DN and the client config is set to "pull DNS"
                  • If I do a direct query to the server DNS with dig @server.dns server-side-FQDN the server-side DNS resolver refuses the query with "requested recursion not available".

                  Where should I look next?

                  V 1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @jhg
                    last edited by

                    @jhg
                    If you request the server side DNS directly either use only the host name or append a dot to the FQDN. Does it work then?

                    J 1 Reply Last reply Reply Quote 0
                    • J
                      jhg @viragomann
                      last edited by jhg

                      @viragomann No I still get WARNING: recursion requested but not available when attempting to resolve server-side hostnames from a client-side host (both Windows and Linux) with or without a trailing dot. The unqualified hostname just returns NXDOMAIN as expected.

                      The frustrating aspect of this is that I also have set up a "Remote Access" OpenVPN which works flawlessly with the Windows OpenVPN Connect client, and resolves DNS just fine. But I'd really like to get peer-to-peer working as well.

                      V 1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @jhg
                        last edited by

                        @jhg
                        Can you show the whole dig output?

                        J 1 Reply Last reply Reply Quote 0
                        • J
                          jhg @viragomann
                          last edited by

                          @viragomann Here is a complete example:

                          ON THE PFSENSE CLIENT BOX (ssh)

                          Query for a client-side host (success)

                          [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: dig home11.jhmg.pvt

; <<>> DiG 9.18.19 <<>> home11.jhmg.pvt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59879
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;home11.jhmg.pvt.               IN      A

;; ANSWER SECTION:
home11.jhmg.pvt.        3600    IN      A       192.168.10.11

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Sep 18 11:09:34 PDT 2024
;; MSG SIZE  rcvd: 60

                          Query for a server-side host (NXDOMAIN)

                          [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: dig nas.goow.lan

; <<>> DiG 9.18.19 <<>> nas.goow.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45776
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;nas.goow.lan.                  IN      A

;; AUTHORITY SECTION:
.                       2345    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2024091800 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Sep 18 11:09:43 PDT 2024
;; MSG SIZE  rcvd: 116

                          Query for a server-side host forced to server-side DNS (also pfSense) host (success)

                          [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: dig @192.168.0.1 nas.goow.lan

; <<>> DiG 9.18.19 <<>> @192.168.0.1 nas.goow.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33635
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1424
;; QUESTION SECTION:
;nas.goow.lan.                  IN      A

;; ANSWER SECTION:
nas.goow.lan.           3600    IN      A       192.168.0.105

;; Query time: 13 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Wed Sep 18 11:09:53 PDT 2024
;; MSG SIZE  rcvd: 57

                          On a linux host in the client-side LAN

                          Query for a client-side host (success)

                          jhg@debian ~
$ dig home11.jhmg.pvt

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> home11.jhmg.pvt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46356
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;home11.jhmg.pvt.               IN      A

;; ANSWER SECTION:
home11.jhmg.pvt.        3600    IN      A       192.168.10.11

;; Query time: 0 msec
;; SERVER: 2601:1c0:5601:6258:201:2eff:fe70:3bfe#53(2601:1c0:5601:6258:201:2eff:fe70:3bfe) (UDP)
;; WHEN: Wed Sep 18 11:15:42 PDT 2024
;; MSG SIZE  rcvd: 60

                          Query for a server-side host (NXDOMAIN)

                          jhg@debian ~
$ dig nas.goow.lan

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> nas.goow.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21833
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;nas.goow.lan.                  IN      A

;; AUTHORITY SECTION:
.                       3563    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2024091800 1800 900 604800 86400

;; Query time: 103 msec
;; SERVER: 2601:1c0:5601:6258:201:2eff:fe70:3bfe#53(2601:1c0:5601:6258:201:2eff:fe70:3bfe) (UDP)
;; WHEN: Wed Sep 18 11:15:50 PDT 2024
;; MSG SIZE  rcvd: 116

                          Query for a server-side host forced to server-side DNS (also pfSense) host (recursion not available)

                          jhg@debian ~
$ dig @192.168.0.1 nas.goow.lan

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @192.168.0.1 nas.goow.lan
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24048
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 11 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Wed Sep 18 11:16:07 PDT 2024
;; MSG SIZE  rcvd: 12

                          Some additional info (client linux host)

                          ping to server pfSense (success)
                          jhg@debian ~
$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=14.1 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=10.4 ms
^C
--- 192.168.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.417/12.269/14.122/1.852 ms
                          traceroute with ICMP to server pfSense (success)
                          jhg@debian ~
$ sudo traceroute -In 192.168.0.1
[sudo] password for jhg:
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 60 byte packets
 1  192.168.10.254  0.324 ms  0.288 ms  0.287 ms
 2  192.168.0.1  14.059 ms  14.058 ms  14.057 ms
                          traceroute with UDP to server LAN host (success)
                          jhg@debian ~
$ sudo traceroute -n 192.168.0.69
traceroute to 192.168.0.69 (192.168.0.69), 30 hops max, 60 byte packets
 1  192.168.10.254  0.281 ms  0.386 ms  0.267 ms
 2  192.168.21.1  14.327 ms  14.323 ms  14.319 ms
 3  192.168.0.69  14.334 ms *  14.325 ms
                          V 1 Reply Last reply Reply Quote 0
                          • V
                            viragomann @jhg
                            last edited by

                            @jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                            Query for a server-side host (NXDOMAIN)

                            jhg@debian ~
                            $ dig nas.goow.lan

                            ; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> nas.goow.lan
                            ;; global options: +cmd
                            ;; Got answer:
                            ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21833
                            ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

                            And you have configured a domain override for goow.lan and pointed it to the remote DNS server?
                            And also set the custom option as described above?

                            Query for a server-side host forced to server-side DNS (also pfSense) host (recursion not available)

                            jhg@debian ~
                            $ dig @192.168.0.1 nas.goow.lan

                            ; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @192.168.0.1 nas.goow.lan
                            ; (1 server found)
                            ;; global options: +cmd
                            ;; Got answer:
                            ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 24048
                            ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
                            ;; WARNING: recursion requested but not available

                            This query was refused bei the DNS server. Maybe the client pfSense is refused as well.

                            You have to add ACLs to the server side DNS server for the client side LAN network and the OpenVPN tunnel network (used by the client pfSense).

                            Also ensure, that the OpenVPN is selected at "Network Interfaces" in the resolver settings if you have not selected "All".
                            This might presume, that you have assigned an interface to the OpenVPN server instance.

                            J 1 Reply Last reply Reply Quote 0
                            • J
                              jhg @viragomann
                              last edited by jhg

                              @viragomann said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                              You have to add ACLs to the server side DNS server for the client side LAN network and the OpenVPN tunnel network (used by the client pfSense).

                              Then why does my "remote access" VPN to the same server, with Windows "OpenVPN Connect" client not require any of this? Everything, including DNS, just works, configured using the .ovpn file created with Client Export. It's rather surprising that peer-to-peer takes so many after-the-fact hacks to get working while "remote access" was trivial? Something here doesn't seem right.

                              I added the ACL on the server side and now directed DNS (i.e. dig @[server-dns] hostname) now works, but it still doesn't work without specifying the server. Again, this all just works without any extra configuration changes on the "remote access" VPN.

                              @viragomann said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                              Also ensure, that the OpenVPN is selected at "Network Interfaces" in the resolver settings if you have not selected "All".

                              "All" is selected... also the OpenVPN interface does not appear in the list.

                              The only missing piece now is getting the client pfSense resolver to recognize and resolve queries for the server-side LAN.

                              Monitoring DNS traffic with tcpdump, what I see is that when a client-side host issues a query for a server-side hostname (FQDN, with or without a trailing doc), the NXDOMAIN originates at the client side resolver. There is no attempt to forward the query via any other interface (VPN or WAN).

                              So next I tried adding a client-side Resolver Domain Override. Now instead of an immediate NXDOMAIN the request from a LAN host times out, but a directed query works. What I see in the packet trace is that the non-directed query appears to originate from 192.168.21.0 (???) which is the tunnel interface's network (i.e. not a valid source IP address), while the directed query originates from the querying host's IP and resolves. Seeing a packet with an invalid source address indicates to me there's clearly a bug somewhere.

                              Here's the tcpdump trace. The first line is the undirected (dig server.lan.host) query showing the invalid source IP address. The second and third lines are from the directed (dig @192.168.0.1 ...) query.

                              [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: tcpdump -ni ovpnc1 'not host 1.1.1.1 and ( port 53 or 853 )'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), snapshot length 262144 bytes
18:06:50.429136 IP 192.168.21.0.25687 > 192.168.0.1.53: 31725+ [1au] A? portal.goow.lan. (44)
18:07:10.166701 IP 192.168.10.8.52665 > 192.168.0.1.53: 42081+ [1au] A? portal.goow.lan. (56)
18:07:10.180220 IP 192.168.0.1.53 > 192.168.10.8.52665: 42081* 1/0/1 A 192.168.0.69 (60)

                              I feel like I'm playing whack-a-mole here for something that shouldn't be this hard.

                              V 1 Reply Last reply Reply Quote 0
                              • V
                                viragomann @jhg
                                last edited by

                                @jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                                Then why does my "remote access" VPN to the same server, with Windows "OpenVPN Connect" client not require any of this?

                                The remote access client gets a virtual IP out of the servers tunnel subnet. He uses this to access server side resources.
                                The tunnel network is considered as a local network in pfSense.

                                However, if you access the remote DNS server across a site to site VPN, the clients IP is unknown on the server. Hence you have to create an ACL for the clients LAN.

                                @jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                                What I see in the packet trace is that the non-directed query appears to originate from 192.168.21.0 (???) which is the tunnel interface's network (i.e. not a valid source IP address)

                                That's strange. I'd expect to see the clients VPN IP as source.

                                I just verified this on on of my installations, where I have exactly configured, what your need, an OpenVPN client connection to a server with DNS domain override to the remote DNS server.
                                I started a capture on the client interface and ran an nslookup for an (not-existing) host in the remote domain on a local Windows host.
                                Then in the capture output I saw packets originating from the virtual clients IP as expected.
                                So there might be something wrong in your setup apart from the DNS.

                                What if you capture a ping from a client host to the server side?

                                J 1 Reply Last reply Reply Quote 0
                                • J
                                  jhg @viragomann
                                  last edited by

                                  @viragomann said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                                  What if you capture a ping from a client host to the server side?

                                  That looks completely normal. I set up tcpdump on all 4 interfaces (client LAN, client VPN, server VPN, server LAN) and everything has the correct source/destination addresses.

                                  for completeness, here are the ping traces at all 4 points. Ping was performed from a Windows host on the client network (192.168.10.11) to a Linux host on the server LAN (192.168.0.69).

                                  Client pfSense LAN interface (re0)

                                  [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: tcpdump -ni re0 icmp and host 192.168.10.11
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on re0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:12:58.041207 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 0, length 64
22:12:58.052766 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 0, length 64
22:12:59.046783 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 1, length 64
22:12:59.058258 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 1, length 64
22:13:00.058654 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 2, length 64
22:13:00.071337 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 2, length 64
22:13:01.068365 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 3, length 64
22:13:01.080533 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 3, length 64

                                  Client pfSense VPN tunnel (ovpnc1)

                                  [2.7.2-RELEASE][admin@janus.jhmg.pvt]/root: tcpdump -ni ovpnc1 icmp and host 192.168.10.11
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), snapshot length 262144 bytes
22:12:58.041281 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 0, length 64
22:12:58.052737 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 0, length 64
22:12:59.046816 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 1, length 64
22:12:59.058241 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 1, length 64
22:13:00.058704 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 2, length 64
22:13:00.071292 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 2, length 64
22:13:01.068392 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 3, length 64
22:13:01.080514 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 3, length 64

                                  Server pfSense VPN tunnel (ovpns2)

                                  [2.7.2-RELEASE][admin@fw.goow.lan]/root: tcpdump -ni ovpns2 icmp and host 192.168.10.11
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ovpns2, link-type NULL (BSD loopback), snapshot length 262144 bytes
22:12:58.045832 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 0, length 64
22:12:58.046197 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 0, length 64
22:12:59.051375 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 1, length 64
22:12:59.051793 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 1, length 64
22:13:00.064454 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 2, length 64
22:13:00.064898 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 2, length 64
22:13:01.074030 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 3, length 64
22:13:01.074303 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 3, length 64

                                  Server pfSense LAN interface (re1)

                                  [2.7.2-RELEASE][admin@fw.goow.lan]/root: tcpdump -ni re1 icmp and host 192.168.10.11
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on re1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:12:58.045860 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 0, length 64
22:12:58.046190 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 0, length 64
22:12:59.051392 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 1, length 64
22:12:59.051788 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 1, length 64
22:13:00.064480 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 2, length 64
22:13:00.064886 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 2, length 64
22:13:01.074044 IP 192.168.10.11 > 192.168.0.69: ICMP echo request, id 2336, seq 3, length 64
22:13:01.074295 IP 192.168.0.69 > 192.168.10.11: ICMP echo reply, id 2336, seq 3, length 64
                                  J 1 Reply Last reply Reply Quote 0
                                  • J
                                    jhg @jhg
                                    last edited by

                                    @viragomann Found it:

                                    System/General Setup/DNS Server Override seems to be a global setting that enables/disables the required functionality. For some reason it was disabled on my client pfSense.

                                    It seems you need all of the following non-default settings

                                    Client

                                    • System/General Setup/DNS Server Override ON
                                    • DNS Resolver/Domain Override: [server domain]->[server DNS IP address]
                                    • VPN Client/Tunnel Settings/"Pull DNS"
                                    • Custom firewall rule on OpenVPN interface to allow incoming traffic

                                    Server

                                    • DNS Resolver: add an ACL permitting the remote LAN to query the server's DNS resolver

                                    Some comments:

                                    • If you use the wizard to create multiple VPNs you'll get duplicate firewall rules for incoming VPN traffic

                                    • The "Pull DNS" setting (VPN/OpenVPN/Edit Client/Tunnel Settings) has the comment

                                      If this option is set, pfSense will use DNS servers assigned by remote OpenVPN server for its own purposes (including the DNS Forwarder/DNS Resolver).

                                      This needs to mention that it is overridden by the System/General Setup/DNS Server Override and has no effect if that setting is OFF.

                                    V 1 Reply Last reply Reply Quote 0
                                    • V
                                      viragomann @jhg
                                      last edited by

                                      @jhg said in OpenVPN pfSense to pfSense (peer-to-peer) connected but not routing:

                                      It seems you need all of the following non-default settings
                                      Client

                                      System/General Setup/DNS Server Override ON

                                      As mentioned multiple times, I think, this setting affects pfSense itself only, as long as you have not enabled DNS forwarding in the Resolver.
                                      You still didn't mention if you have this.

                                      Anyway, it has no affect on a domains, which you have configured an override for.

                                      VPN Client/Tunnel Settings/"Pull DNS"

                                      This also has no affect on a domains, which you have configured an override for. So you don't need to set this for your purposes and I never suggested to enable this option.

                                      Custom firewall rule on OpenVPN interface to allow incoming traffic

                                      That's pretty plausible. pfSense is a firewall, all intended traffic needs a rule.

                                      Server

                                      DNS Resolver: add an ACL permitting the remote LAN to query the server's DNS resolver

                                      That's by design of Unbound (DNS Resolver). You need ACLs for all unknown source IPs.

                                      Some comments:

                                      If you use the wizard to create multiple VPNs you'll get duplicate firewall rules for incoming VPN traffic

                                      Also note, that the rule tab "OpenVPN" is in fact an interface group including all OpenVPN instances your are running, can be servers or clients. Hence rules, you add there are applied to all.
                                      For better separation you can assign interfaces to the OpenVPN instances. However, remember that rules on the interface group have priority over ones on a member interface.

                                      1 Reply Last reply Reply Quote 0
                                      • First post
                                        Last post