1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

LAN-to-LAN bridging with VPN

Discussion in 'Tomato Firmware' started by seron, Jan 11, 2010.

  1. seron

    seron LI Guru Member

    I'm having a hard time bridging two LANs together with VPN. I've tried following the thread Bridging Two LANs through a VPN but to no avail.

    I think I have the authentication part of VPN working as my Client router receives an IP address from the VPN server, but then I'm stuck. From the Client LAN side I can only ping that single IP address and no other from the VPN server LAN. Just like in the thread mentioned above both LANs work fine on their own. However in my case LANs are on different subnets.

    Here's my setup (extracted from routers through ssh):

    VPN server router (192.168.2.251/255.255.255.0):

    Code:
    # cat /etc/openvpn/server2/config.ovpn 
    # Automatically generated configuration
    daemon
    server-bridge 192.168.2.251 255.255.255.0 192.168.2.170 192.168.2.189
    proto udp
    port 1194
    dev tap22
    cipher AES-256-CBC
    keepalive 15 60
    verb 3
    tls-auth static.key 0
    ca ca.crt
    dh dh.pem
    cert server.crt
    key server.key
    status-version 2
    status status
    
    # Custom Configuration
    keepalive 10 60
    persist-key
    persist-tun
    user nobody
    group nobody
    fragment 1500
    
    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    server.isp.i.p  0.0.0.0         255.255.255.128 U     0      0        0 vlan1
    192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
    127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
    0.0.0.0         server.isp.i.p  0.0.0.0         UG    0      0        0 vlan1
    "Manage Client-Specific Options" is enabled
    "Allow Client<->Client" is enabled

    VPN client router (192.168.3.252/255.255.255.0):
    Code:
    # cat /etc/openvpn/client2/config.ovpn
    # Automatically generated configuration
    daemon
    client
    dev tap12
    proto udp
    remote server.address 1194
    resolv-retry 30
    nobind
    persist-key
    persist-tun
    comp-lzo no
    cipher AES-256-CBC
    verb 3
    tls-auth static.key 1
    ca ca.crt
    cert client.crt
    key client.key
    status-version 2
    status status
    
    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
    192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 tap12
    127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
    0.0.0.0         client.isp.i.p  0.0.0.0         UG    0      0        0 vlan1
    "Server is on the same subnet" is disabled. Message "Warning: Cannot bridge distinct subnets. Defaulting to routed mode." is displayed. I understand subnets are distinct, but don't understand what router mode means.
    "Create NAT on tunnel" is disabled. Message "Routes must be configured manually." is displayed. I don't know how to do this.
    Under Advanced->Routing "Mode" is set to "Gateway" and "RIPv1 & v2" is disabled.

    I haven't opened any ports in any firewalls for this. Should I have? I can successfully connect with an openvpn client from a Mac without having done so.

    I've been struggling for a few days and am at my wits end. I'd be thankful for any help.
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Since you are using two different subnets, you'd be better off using TUN instead of TAP.

    Then, have a look at this blog post on how to get site-to-site routing working.
     
  3. seron

    seron LI Guru Member

    Thanks for you reply and the link.

    I reconfigured with TUN and have disabled NAT on the client and have Client<->Client enabled on the server, as described in your link. Unfortunately it didn't get better nor worse. Still I'm only able to ping, from the client LAN, the one ip-address pushed over from the VPN server. However my routing tables look slightly different.

    Server:
    Code:
    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun22
    server.isp.i.p  0.0.0.0         255.255.255.128 U     0      0        0 vlan1
    192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun22
    127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
    0.0.0.0         server.isp.i.p  0.0.0.0         UG    0      0        0 vlan1
    Client:
    Code:
    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun12
    192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
    192.168.2.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun12
    10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun12
    127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
    0.0.0.0         client.isp.i.p  0.0.0.0         UG    0      0        0 vlan1
    The IP pushed over from the Server is 10.8.0.6 where the VPN subnet/netmask is set to 10.8.0.0/255.255.255.0.
    On the client status pane there's no traffic, but there is TCP/UDP traffic.

    To me the routing tables look ok. However I can't ping 10.8.0.5 from the client. To my understanding 10.8.0.5 is set up as gateway for the 192.168.2.0 and 10.8.0.0 networks and pings to these networks should be transmitted through the VPN tunnel, but since 10.8.0.5 is not responding neither is any requests directed through it. It makes sense to me, but I might have it backwards. I've only just started looking at routing tables.
     
  4. gawd0wns

    gawd0wns LI Guru Member

  5. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    From your routing table, it looks like the Client-specific options table is not filled out properly. The server needs to have a 192.168.3.0/24 route before it will work. Make sure you have the correct name in the CommonName field. To help debug that, select "Allow Only These Clients". That way, if you don't have the right CommonName filled in, it won't even allow the client to connect.
     
  6. seron

    seron LI Guru Member

    I don't understand how the CommonName should be used. I followed the OpenVPN PKI guide and made new server and client certificates and keys with all fields being the same except for the CN field so that the option "Allow Only These Clients" can distinguish between clients.

    Following your suggestion I enabled this option, and as you say authentication fails. So I'm stuck again.

    I don't have access to the client router at the moment and am testing your suggestions using a Mac user client. On the bright side I can connect using TUN when "Allow Only These Clients" is disabled. Maybe at least that will work when I move over the files to the Client router.

    As a side note, while trying to follow your last suggestion I put the server router subnet into the list of allowed clients which made the server router completely unreachable. I guess it totally messed up its routing table. So that's why I'm on the Server router side today.
     
  7. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    The CommonName, as you say, is used during creation of certificates. Each certificate should have a unique CommonName. It's not just the "Allow Only These Clients" that needs to distinguish between them. It's just that when that option is enabled, it makes it more apparent that a mistake has been made in entering the CommonName in the table.

    If enabling that option caused authentication to fail, then the CommonName you entered in the Client-specific options table doesn't match the one used in generating the client certificate. That would explain why the routing doesn't work when you don't have the option selected (the client-specific options table entry isn't being used because it doesn't match).

    Yeah, that'd definitely confuse the routing table. Only the subnets for the client LANs associated with the CommonName (if any) should be placed in the table.
     
  8. seron

    seron LI Guru Member

    After enabling 'Allow Only These Clients' I entered 'seron' (without quotes) in the CN field and left the others blank.

    From the server router log I have this. The file ccd/seron (line 2) is empty.
    Code:
    Jan 13 22:13:10 server daemon.notice openvpn[10130]: 11.22.33.44:49337 VERIFY OK: depth=0, /C=SE/ST=Scania/L=Malmo/O=na/CN=seron/Email=me@myhost.mydomain
    Jan 13 22:13:17 server daemon.err openvpn[10130]: 11.22.33.44:49337 TLS Auth Error: --client-config-dir authentication failed for common name 'seron' file='ccd/seron'
    Jan 13 22:13:17 server daemon.notice openvpn[10130]: 11.22.33.44:49337 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 2048 bit RSA
    Jan 13 22:13:17 server daemon.notice openvpn[10130]: 11.22.33.44:49337 [seron] Peer Connection Initiated with 11.22.33.44:49337
    Jan 13 22:13:18 server daemon.notice openvpn[10130]: 11.22.33.44:49337 PUSH: Received control message: 'PUSH_REQUEST'
    Jan 13 22:13:18 server daemon.notice openvpn[10130]: 11.22.33.44:49337 Delayed exit in 5 seconds
    Jan 13 22:13:18 server daemon.notice openvpn[10130]: 11.22.33.44:49337 SENT CONTROL [seron]: 'AUTH_FAILED' (status=1)
    Jan 13 22:13:23 server daemon.notice openvpn[10130]: 11.22.33.44:49337 SIGTERM[soft,delayed-exit] received, client-instance exiting
    This part is from the client certificate. CN differs on the first and last line.
    Code:
            Issuer: C=SE, ST=Scania, L=Malmo, O=na, CN=server/emailAddress=me@myhost.mydomain
            Validity
                Not Before: Jan 11 20:39:12 2010 GMT
                Not After : Jan  9 20:39:12 2020 GMT
            Subject: C=SE, ST=Scania, L=Malmo, O=na, CN=seron/emailAddress=me@myhost.mydomain
    
    Could any of this cause the problem?
     
  9. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Hmmm, I wonder if your "user nobody" and "group nobody" lines in your custom config are making it so it can't read the ccd files...

    The ccd file is supposed to be blank if you don't have any subnet info there. That isn't a problem. However, the fact the file is there, you got the CommonName correct, and it still failed client-config-dir authentication, makes me think that it couldn't read that file. If it's there and it can't read it, it sounds like a permissions problem to me.

    Try it without those two lines.
     
  10. seron

    seron LI Guru Member

    Yes! It worked after removing those lines!

    Thank you very much for all your help! First class.
     
  11. seron

    seron LI Guru Member

    I have it working on the Client router too now. Again, thank you for all the help.

    As I'm using a Mac I'd like other computers to be visible in Finder. When using tap they are (but only if I connect with a VPN Client on a user computer). If I set the Client router to use tap I can't ping in either direction over the tunnel. (Both 'Server is on the same subnet' and 'Create NAT on tunnel' are unchecked). I guess some routing information needs to be added, but don't know how that is done and which tables need to be amended (routers, user computers?).

    If I set the client router to use tun on the other hand, other computers are not visible in Finder, but can be connected to if you know their IP.

    I'd like to be able to both see other computers in Finder and have Client LANs with arbitrary network addresses share the same LAN as the Server router. I can do one or the other, but is it possible to do both? In most cases I have no control over the Client network configuration so the setting 'Server is on the same subnet' is perhaps not a viable option.
     

Share This Page