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

    Route WAN network to OVPN

    Scheduled Pinned Locked Moved General pfSense Questions
    19 Posts 2 Posters 1.8k Views
    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.
    • D
      DasK
      last edited by DasK

      Thanks for reply.

      No there is anything blocked, I allow everything into the firewall rules.
      Proxmox don't have an IP in the 10.23.1.0/24 tunnel.

      I just added a rule to tell proxmox to communicate to the 10.23.1.0/24 tunnel via 10.1.1.2(pfSense)

      ip route add 10.23.1.0/24 via 10.1.1.2
      

      So my proxmox server know where to go to communicate with 10.23.1.0/24 network.
      The thing I don't understand is why ping is working, but not traceroute or rpcinfo, if I do a traceroute -I it work.
      But well, in final I need this rpc working to etablish a NFS storage.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator @DasK
        last edited by

        @DasK said in Route WAN network to OVPN:

        The ip: 10.23.1.200 is the IP of the proxmox on the vpn network

        Then what did you mean by that? A different Proxmox server?

        Steve

        1 Reply Last reply Reply Quote 0
        • D
          DasK
          last edited by DasK

          Ok I'm sorry, I was meaning the IP of the pfSense, my bad

          Proxmox IP: 10.1.1.1
          PfSense WAN IP: 10.1.1.2
          PfSense LAN IP: 192.168.10.254
          PfSense VPN IP: 10.23.1.200
          VPN NETWORK: 10.23.1.0/24

          And the server I try to communicate with on the VPN is : 10.23.1.100

          Outbound rules (without this, proxmox can't ping 10.23.1.100 anymore)
          f7e68811-9f28-4dbb-80bb-d4cea4836e97-image.png

          Interfaces
          68580d68-37a7-4db9-b423-6d406710b9aa-image.png

          Wan rules
          9e837633-8910-412b-b1f1-40908c79675d-image.png

          Lan rules
          a846fc18-042b-4962-bb21-b6a28b9afbf7-image.png

          OPT1 rules
          921c8484-5d24-4bf6-8bf4-e8064d2f74d2-image.png

          Routes
          d2078683-c847-47d7-a22f-c8e1fc198c64-image.png

          pfSense traceroute:
          alt text

          pfSense rpcinfo:
          alt text

          Proxmox traceroute:
          ce7a828b-f205-4f1b-8acf-2ebc68e60065-image.png

          Proxmox rpcinfo:
          962e0997-2189-4e34-afb7-4d3a6efd504e-image.png

          Proxmox ping:
          29622625-b522-4db6-8ce6-d795089610e4-image.png

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hmm, you might have to check the OpenVPN server, it's able to reach that at 10.23.1.1 but no further. Something blocking or re-routing it there maybe?

            Hard to imagine what the difference might be there though. It could only really be TTL....

            You probably need that outbound NAT rule as those target devices otherwise have no route back.

            Steve

            1 Reply Last reply Reply Quote 0
            • D
              DasK
              last edited by

              All if good for the OpenVPN server.

              Any example of how "outbound NAT rule as those target devices " ?

              Best

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                The rule you already have for source NATing 10.1.1.0/30 to 10.23.1.200.

                Devices at 10.23.1.100 (and .1) obviously know how to reach 10.23.1.200 but probably have no route to 10.1.1.0/30. That is the reason you need that rule.

                Steve

                1 Reply Last reply Reply Quote 0
                • D
                  DasK
                  last edited by

                  I added the rule, but still the same problem

                  1 Reply Last reply Reply Quote 0
                  • D
                    DasK
                    last edited by

                    Well I think I'll give up and just also connect the proxmox server to the VPN, so there will be a direct connection to both server.. It just look weird to connect proxmox to VPN, when there is a VM pfSense already connected to this VPN

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      We haven't yet seen a packet capture of a TCP connection failing. That should be revealing. If there is no traffic coming back at all for example.

                      This still looks like some route asymmetry somewhere.

                      Does an icmp traceroute succeed?

                      Steve

                      1 Reply Last reply Reply Quote 0
                      • D
                        DasK
                        last edited by

                        Yes all ICMP traceroute work, like ping.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          When you have ICMP works but TCP fails it's usually an asymmetric routing problem.

                          It can also be a packet size issue but that would not normally affect UDP traceroute.

                          Or it can be a hardware off loading problem if the a NIC/driver somewhere is not doing what it reports it can.

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • D
                            DasK
                            last edited by

                            How does I can solve this asymetric routing problem ? Or detect where is located the routing problem.

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Run a packet capture showing some TCP connection failing. If you see parts of the TCP setup missing they are either being blocked somewhere or routed some other way.

                              Steve

                              1 Reply Last reply Reply Quote 0
                              • D
                                DasK
                                last edited by DasK

                                There is a little diagram, if that can help to understand how is setup

                                db312123-0f2a-4488-b534-0d7b9062e3c5-image.png

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  Yeah, there is some difference between what happens when you run, say, rpcinfo from pfSense directly and when it's run from Proxmox. So I would run a pcap on the OpenVPN interface and compare them.

                                  rpcinfo will create quite a lot of output so you might want to use something simpler like just telneting to a port assuming that also fails from Proxmox.

                                  Steve

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.