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

    Simple routing problem, lan <-> vpn lan

    Scheduled Pinned Locked Moved OpenVPN
    7 Posts 2 Posters 2.3k 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.
    • B
      bufflo
      last edited by

      Hello,

      I have a very simple question/problem, but I just couldnt figure out whats wrong. My LAN has the IP range 10.0.0.1-254, where .1 is my router with ISP access. The router connects to a OpenVPN server which has a local lan behind it with the ip range 192.168.1.1-254. The client ip of the VPN connection is 192.168.1.240.

      If connected, I can reach (ping) the IPs of the VPN LAN side on the router. But I cannot reach the 192.168.1.0 subnet from my clients behind the router (for example: ping 192.168.1.1 from 10.0.0.2). Heres my routing table from the router:

      Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
      default        10.0.1.1        0.0.0.0        UG    0      0        0 eth1
      10.0.0.0        *              255.255.255.0  U    0      0        0 br-lan
      10.0.1.0        *              255.255.255.0  U    0      0        0 eth1
      172.20.16.0    *              255.255.248.0  U    0      0        0 tun0
      172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
      192.168.1.0    *              255.255.255.0  U    0      0        0 tap0

      tap0 is the OpenVPN connection. Shouldnt that work already?
      vpn.gif
      vpn.gif_thumb

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        Seems like you vpn network is the same as the remote network??  That doesn't work..  So you have this

        10.0.0.0/24 pfsense publicIP –- internet ---- publicIP pfsense 192.168.1.0/24

        What you want to use is a different tunnel network than what is on both sides of the vpn.. So you have something like this

        10.0.0.0/24 pfsense publicIP --- vpn 172.31.254.1 internet 172.31.254.2 vpn ---- publicIP pfsense 192.168.1.0/24

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • B
          bufflo
          last edited by

          Hello,

          what you mean it doesnt work? Of course does it work. The OpenVPN server is in bridge mode:

          option 'server_bridge' '192.168.1.1 255.255.255.0 192.168.1.240 192.168.1.242'

          I already can ping the OpenVPN server itself (192.168.1.1) and all clients on its lan. But just from the Router (VPN client), and not from my local lan clients (routing problem). See what I mean? I can reach all clients on the OpenVPN server side lan. But just from the machine where I initiate the connection from (my router). I cant reach the 192.168.1.0 subnet from my clients behind my router, and this is just a routing problem, but I coudlnt figure out yet what to do for solving this.

          1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator
            last edited by

            Do a traceroute from your clients..

            Ahhh didn't see that at first – I would never do such a setup, what is the point?  I could see having to bridge if both sides where on the same network space..  Why can you just not do a normal tun connection?

            Here is thread on openvpn bridging http://forum.pfsense.org/index.php?topic=38605.0

            I just don't see the reason for it - if had to locations that needed to be connected via vpn, I would renumber 1 side before going bridge mode, etc.

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            1 Reply Last reply Reply Quote 0
            • B
              bufflo
              last edited by

              And why not use it this way? Whats the disadvantage of it? ALso your hint with doing a traceroute from the lan clients did the trick showing why it's not working:

              Routenverfolgung zu 192.168.1.1 über maximal 30 Hops

              1    1 ms    1 ms    <1 ms  201.lan [10.0.0.1]
                2    43 ms    19 ms    16 ms  172.20.16.1
                3    *        *        *    Zeitüberschreitung der Anforderung.
                4  ^C

              It goes the wrong direction. But why? It goes over 172.20.16.1 which is another vpn connection. But I cant see why it goes this direction. The routing table should tell it has to go through tap0:

              Kernel IP routing table
              Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
              default        10.0.1.1        0.0.0.0        UG    0      0        0 eth1
              10.0.0.0        *              255.255.255.0  U    0      0        0 br-lan
              10.0.1.0        *              255.255.255.0  U    0      0        0 eth1
              172.20.16.0    *              255.255.248.0  U    0      0        0 tun0
              172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
              192.168.1.0    *              255.255.255.0  U    0      0        0 tap0

              default via 10.0.1.1 dev eth1  proto static
              10.0.0.0/24 dev br-lan  proto kernel  scope link  src 10.0.0.1
              10.0.1.0/24 dev eth1  proto kernel  scope link  src 10.0.1.1
              172.20.16.0/21 dev tun0  proto kernel  scope link  src 172.20.16.2
              172.20.24.0/21 dev tun1  proto kernel  scope link  src 172.20.24.4
              192.168.1.0/24 dev tap0  proto kernel  scope link  src 192.168.1.240

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                "Whats the disadvantage of it? "

                bridge over a wan connection – all broadcast traffic is sent over a bridge, why would you want broadcast traffic over a wan based vpn?

                How are you looking at your routing table.. Can you just post up the screen shot from the gui?  Also do you have any policy based routing setup in your firewall rules to use specific gateway?  This would be used before the routing table.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                1 Reply Last reply Reply Quote 0
                • B
                  bufflo
                  last edited by

                  Hello,

                  sorry for my late reply, Christmas time was a bit hectic :( Thanks again and you were right again. There was a policy based routing rule I didnt thinkt about, something like this:

                  iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -j MARK –set-mark 2

                  And I set anoher one which solved the issue:

                  iptables -t mangle -A PREROUTING -d 192.168.1.0/24 -j MARK --set-mark 1

                  But now I have nother problem :/ I read myself into why I should use tun instead of tap and not bridging, because like you said it would produce lots of broadcast traffic for example. So I changed my server config to this:

                  config 'openvpn' 'lan'
	option 'enable' '1'
	option 'port' '1194'
	option 'proto' 'udp'
	option 'dev' 'tun2'
	option 'ca' '/etc/easy-rsa/keys/ca.crt'
	option 'cert' '/etc/easy-rsa/keys/server.crt'
	option 'key' '/etc/easy-rsa/keys/server.key'
	option 'dh' '/etc/easy-rsa/keys/dh2048.pem'
	#option 'ifconfig_pool_persist' '/tmp/ipp.txt'
	#option 'ifconfig-pool' '10.8.0.2 10.8.0.10 255.255.255.0'
	option 'keepalive' '10 120'
	option 'comp_lzo' '0'
	option 'persist_key' '1'
	option 'persist_tun' '1'
	option 'status' '/tmp/openvpn-status.log'
	option 'verb' '3'
	#option 'server_bridge' '192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.205'
	option server "10.8.0.0 255.255.255.0"
	list push "route 192.168.1.0 255.255.255.0"

                  But again I cant get it to work, and it's even worse now than before with the bridging, where in the end I got it to work.

                  First confusing thing is that it shows this on the client:

                  tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
                            inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255

                  And on the server:

                  tun2      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
                            inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255

                  Why two adresses for each? and why does the client get 6 (and 5?) and not 2? Also I cant even ping from side to side from the client to the server. My routing table looks a little bit weird too:

                  Kernel IP routing table
                  Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
                  default        10.0.1.1        0.0.0.0        UG    0      0        0 eth1
                  10.0.0.0        *              255.255.255.0  U    0      0        0 br-lan
                  10.0.1.0        *              255.255.255.0  U    0      0        0 eth1
                  10.8.0.1        10.8.0.5        255.255.255.255 UGH  0      0        0 tun2
                  10.8.0.5        *              255.255.255.255 UH    0      0        0 tun2
                  172.20.16.0    *              255.255.248.0  U    0      0        0 tun0
                  172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
                  192.168.1.0    10.8.0.5        255.255.255.0  UG    0      0        0 tun2

                  And on the server:

                  Kernel IP routing table
                  Destination    Gateway        Genmask        Flags Metric Ref    Use Iface
                  default        188-194-- 0.0.0.0        UG    0      0        0 eth1
                  10.8.0.0        10.8.0.2        255.255.255.0  UG    0      0        0 tun2
                  10.8.0.2        *              255.255.255.255 UH    0      0        0 tun2
                  172.20.24.0    *              255.255.248.0  U    0      0        0 tun1
                  172.20.24.0    *              255.255.248.0  U    0      0        0 tun0
                  188.194.*.0  *              255.255.255.0  U    0      0        0 eth1
                  192.168.1.0    *              255.255.255.0  U    0      0        0 br-lan

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