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

    Openvpn, lan and wan trouble

    Scheduled Pinned Locked Moved OpenVPN
    14 Posts 3 Posters 7.6k 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.
    • M
      msund
      last edited by

      Hi!

      Ive got openvpn running om my pfsense box which has a wan, lan and a optiona (dmz) interface.
      The lan and dmz interface rules allow the appropriate subnet access to anything "allow dmz > any" "allow lan > any"
      I read that the openvpn subnet is allowed everywhere without the need for rules, so i didnt make any rules either.

      The problem im having is that i cant from the openvpn subnet acccess internet or the lan subnet, only the dmz net is avalible.
      Allthough hosts from the lan net can ping the openvpn hosts, the openvpnhosts cant ping the lan hosts  :-\

      My default route gets set correctly to my tun0 interface on the openvpn client machine
      default        13.37.2.5      0.0.0.0        UG    0      0        0 tun0

      So all traffic towards the internet is atleast going out to the openvpn net gateway on my pfsense box.

      Ive set the Local network configuration to 13.37.0.0 /24
      and i push the route 13.37.1.0 /24 for my dmz net

      Allthoguh this is the only entry i get in my routing table on the client.
      13.37.0.0      13.37.2.5      255.255.255.0  UG    0      0        0 tun0

      Which is strange since i can access 13.37.1.0 /24 net, but not the 13.37.0.0 /24 net "Which is in my routing table"…

      Any help or comments would be nice.

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

        Did you look at the openVPN log on the server and the client?
        You say you added the additional route to the custom options, but are they in the right format?

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • M
          msund
          last edited by

          The things i push looks as follow
          push "route 13.37.1.0/24";push "dhcp-option DNS 13.37.1.1";push "dhcp-option DOMAIN myrealdomain.com"

          client log

          May  7 10:07:34 suse NetworkManager: <debug>[1273219654.105069] write_to_netconfig(): Writing to netconfig: DNSSERVERS='13.37.1.1'#012
          May  7 10:07:34 suse NetworkManager: <info>  Clearing nscd hosts cache.
          May  7 10:07:34 suse NetworkManager: <info>  VPN connection 'openvpn_1' (IP Config Get) complete.
          May  7 10:07:34 suse NetworkManager: <debug>[1273219654.107123] run_netconfig(): Spawning '/sbin/netconfig modify –service NetworkManager'
          May  7 10:07:34 suse NetworkManager: <debug>[1273219654.115685] write_to_netconfig(): Writing to netconfig: DNSSEARCH='myrealdomain.com myrealdomain.com localdomain.se'#012
          May  7 10:07:34 suse NetworkManager: <debug>[1273219654.115841] write_to_netconfig(): Writing to netconfig: DNSSERVERS='13.37.1.1'#012
          May  7 10:07:34 suse NetworkManager: <info>  Clearing nscd hosts cache.
          May  7 10:07:34 suse NetworkManager: <info>  Policy set 'osund' (tun0) as default for routing and DNS.
          May  7 10:07:34 suse NetworkManager: <info>  VPN plugin state changed: 4
          May  7 10:07:34 suse nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/netcontrol_services' exited with error status 127.

          server logs

          May  7 10:11:40 router openvpn[5595]: TCPv4_SERVER link local: [undef]
          May  7 10:11:40 router openvpn[5595]: TCPv4_SERVER link remote: X.X.X.X:38136
          May  7 10:11:42 router openvpn[5595]: X.X.X.X:38136 [user1] Peer Connection Initiated with X.X.X.X:38136
          May  7 10:12:08 router openvpn[5595]: Re-using SSL/TLS context
          May  7 10:12:08 router openvpn[5595]: TCP connection established with 127.0.0.1:28872
          May  7 10:12:08 router openvpn[5595]: TCPv4_SERVER link local: [undef]
          May  7 10:12:08 router openvpn[5595]: TCPv4_SERVER link remote: 127.0.0.1:28872
          May  7 10:12:08 router openvpn[5595]: 127.0.0.1:28872 WARNING: Bad encapsulated packet length from peer (29556), which must be > 0 and <= 1559 – please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attemping restart…]
          May  7 10:12:08 router openvpn[5595]: 127.0.0.1:28872 Connection reset, restarting [0]

          The only thing going wrong is the clients netcontrol_services script, and the server complains about the mtu, but the connection works just as well.</info></info></info></debug></debug></debug></info></info></debug>

          1 Reply Last reply Reply Quote 0
          • GruensFroeschliG
            GruensFroeschli
            last edited by

            Your format of the push is wrong.
            It has to be:
            push "route 13.37.1.0 255.255.255.0"

            We do what we must, because we can.

            Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

            1 Reply Last reply Reply Quote 0
            • M
              msund
              last edited by

              Solved the problem with openvpn net not being able to connect out to the internet, i automatic nat , when changing to manual and adding all my subnets, the vpn networks outbound traffic to the web started working.

              Still stuck on that darn openvpn net > lan , and a lan host can still ping the openvpn client, but not the other way around…

              Ah! now i get the route correct.

              13.37.1.0      13.37.2.5      255.255.255.0  UG    0      0        0 tun0
              13.37.0.0      13.37.2.5      255.255.255.0  UG    0      0        0 tun0

              but i still cant access the hosts on 13.37.0.0 /24 net  :-\

              1 Reply Last reply Reply Quote 0
              • K
                kpa
                last edited by

                You're using public ip addresses that are registered to Xerox Corporation on your networks, any reason for that? I would change all those 13.x.x.x addresses to 10.x.x.x just to be sure there's no ill effects from using public ip addresses where private rfc1918 addresses would be more appropriate.

                1 Reply Last reply Reply Quote 0
                • M
                  msund
                  last edited by

                  Well the reason is a bit nerdy, the two first octets read 13.37 = 1337 = leet  ;)

                  I read somewhere that unchecking "Block private networks" on the wan interface could help, i tried it with little hope and sure enought it didnt do any good, this problem should be from the tun interface on the pfsense box and the lan interface, not involving wan at all.

                  I dont think that the address scheme has anything to do with the problem since i can reach 13.37.1.0 net but not 13.37.0.0 , even though i have routes and the nets are class C nets, ill try capturing some packets and look more closely at the logs.

                  If nothing else helps ill change the to a 10.x.x.x network..

                  1 Reply Last reply Reply Quote 0
                  • K
                    kpa
                    last edited by

                    Few things to check:

                    Can you reach the LAN gateway address from the client when the vpn connection is open?

                    When connecting to hosts on the LAN make sure they don't have firewall of their own that would block traffic from (their point of view) an unknown network.

                    Are the hosts on the LAN using pfSense as their default gateway or is there another gateway on the LAN net?

                    1 Reply Last reply Reply Quote 0
                    • M
                      msund
                      last edited by

                      Yupp, i can ping 13.37.0.1 which is the gateway for the Lan.

                      The machine im testing against has the firewall turned off.
                      Chain INPUT (policy ACCEPT)
                      target     prot opt source               destination

                      Chain FORWARD (policy ACCEPT)
                      target     prot opt source               destination

                      Chain OUTPUT (policy ACCEPT)
                      target     prot opt source               destination

                      The hosts on the lan has the pfsene lan interface 13.37.0.1 as their gateway.

                      The pfsense box is the only routing machine on my network, combining lan,dmz,wan and openvpn net.

                      Here is the traceroute from the client to machines on dmz resp lan net.

                      Dmz machine 13.37.1.4
                      1:  13.37.2.6 (13.37.2.6)                                  0.092ms pmtu 1500
                      1:  13.37.2.1 (13.37.2.1)                                47.907ms
                      2:  13.37.1.4 (13.37.1.4)                                19.079ms reached
                          Resume: pmtu 1500 hops 2 back 2

                      Lan machine 13.37.0.5
                      1:  13.37.2.6 (13.37.2.6)                                  0.069ms pmtu 1500
                      1:  13.37.2.1 (13.37.2.1)                                18.711ms
                      2:  no reply

                      So it looks like the openvpn gateway adress is the last to respond in the Lan case, but cant forward the packet out on the lan interface.

                      Something gotta be different with the lan and dmz interfaces, since dmz got no problem at all with the openvpn net.

                      1 Reply Last reply Reply Quote 0
                      • GruensFroeschliG
                        GruensFroeschli
                        last edited by

                        Did you make sure that the client you try to ping has no firewall active?

                        We do what we must, because we can.

                        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                        1 Reply Last reply Reply Quote 0
                        • M
                          msund
                          last edited by

                          yupp, tried from two different hosts aswell. same prob

                          1 Reply Last reply Reply Quote 0
                          • GruensFroeschliG
                            GruensFroeschli
                            last edited by

                            Can you do a tcp dump on the LAN interface?

                            We do what we must, because we can.

                            Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                            1 Reply Last reply Reply Quote 0
                            • M
                              msund
                              last edited by

                              http://pastebin.com/R93W8N0r

                              i filtered packets from 13.37.2.6 which is the openvpn client im currently running ssh to in order to make a connection from 13.37.2.6 to 13.37.0.5 via ssh.
                              sadly the only traffic showing up is my ssh session from my own host inside on the lan at 13.37.0.2 , nothing shows for the 13.37.2.6 vpn host trying to make the ssh connection to 13.37.0.5..

                              its a one way street , since all connection from lan > openvpn is successfull but not the other way around, and i have no access-lists to fiddle with either :(

                              one thing that caught my attention is if the nat only works one way, lan traffic gets nated towards all other interfaces, but the tun0 inteface maybe dont have permission to starta a nat against the lan interface for some reason? , its pretty far fetched since ive read that no configuration of rules or nat should have to be done, and plus the nat towards dmz net works fron the tunnel.

                              1 Reply Last reply Reply Quote 0
                              • M
                                msund
                                last edited by

                                After some reading i turned off captive portal… and now it works :)

                                Allthough captive portal is a nice feature im woundering if its supposed to behave this way or if its a bug?
                                Kinda want both openvpn > lan and captive portal to work.

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