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

Site-to-Site VPN Bridge using only the interface

Discussion in 'Tomato Firmware' started by JoAllard, Dec 7, 2010.

  1. JoAllard

    JoAllard Networkin' Nut Member

    Hi,

    It has now been 24 hours that I research left and right to do this and I can't seem to get it anywhere. I'm trying to link two routers in different locations, one using Tomato (the server) and one using DD-WRT (the client).

    Is it possible to use only the interface in Tomato.VPN to do this kind of setup? I meant to use a TAP tunnel but OpenVPN says it has no space to allocate an IP to the incoming connection.
     
  2. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Yes, that kind of setting should be completely configurable in the GUI. Could you give a run-down of your setup and what error message you're getting?
     
  3. JoAllard

    JoAllard Networkin' Nut Member

    Code:
    Start with WAN		[x]
    Interface Type		[TAP]
    Protocol		[UDP]
    Port			[1194]
    Firewall		[Automatic]
    Auth. Mode		[TLS]
    HMAC			[Disabled]
    Client pool		[x] DHCP
    
    Poll Interval		[0]	
    DCRIT			[ ]
    Respond to DNS		[ ]	
    Encryption cipher	[Default]
    Compression		[Adaptive]
    TLS Reneg Time		[-1]
    
    Manage Client-Specific Options	[x]
    Allow Client<->Client		[x]	
    Allow Only These Clients	[ ]
    				
    Custom Configuration
    [				]
    [				]
    [				]
    
    Code:
    Dec  7 19:19:07 ? daemon.notice openvpn[758]: OpenVPN 2.1.1 mipsel-unknown-linux-gnu [SSL] [LZO2] built on Jan 31 2010
    Dec  7 19:19:07 ? daemon.warn openvpn[758]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
    Dec  7 19:19:07 ? daemon.warn openvpn[758]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Dec  7 19:19:08 ? daemon.notice openvpn[758]: Diffie-Hellman initialized with 1024 bit key
    Dec  7 19:19:08 ? daemon.notice openvpn[758]: TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Dec  7 19:19:08 ? daemon.notice openvpn[758]: TUN/TAP device tap21 opened
    Dec  7 19:19:08 ? daemon.notice openvpn[758]: TUN/TAP TX queue length set to 100
    Dec  7 19:19:08 ? daemon.notice openvpn[758]: Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
    Dec  7 19:19:08 ? daemon.notice openvpn[760]: Socket Buffers: R=[32767->65534] S=[32767->65534]
    Dec  7 19:19:08 ? daemon.notice openvpn[760]: UDPv4 link local (bound): [undef]:1194
    Dec  7 19:19:08 ? daemon.notice openvpn[760]: UDPv4 link remote: [undef]
    Dec  7 19:19:08 ? daemon.notice openvpn[760]: MULTI: multi_init called, r=256 v=256
    Dec  7 19:19:08 ? daemon.notice openvpn[760]: Initialization Sequence Completed
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: MULTI: multi_create_instance called
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Re-using SSL/TLS context
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: 66.36.154.38:2287 LZO compression initialized
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
    Dec  7 19:20:04 ? daemon.notice openvpn[760]: 66.36.154.38:2287 TLS: Initial packet from 66.36.154.38:2287, sid=3304e386 fcb8e193
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 VERIFY OK: depth=1, [...]
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 VERIFY OK: depth=0, [...]
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
    Dec  7 19:20:06 ? daemon.notice openvpn[760]: 66.36.154.38:2287 [Schulz] Peer Connection Initiated with 66.36.154.38:2287
    Dec  7 19:20:06 ? daemon.err openvpn[760]: Schulz/66.36.154.38:2287 MULTI: no dynamic or static remote --ifconfig address is available for Schulz/66.36.154.38:2287
    Dec  7 19:20:08 ? daemon.notice openvpn[760]: Schulz/66.36.154.38:2287 PUSH: Received control message: 'PUSH_REQUEST'
    Dec  7 19:20:08 ? daemon.notice openvpn[760]: Schulz/66.36.154.38:2287 SENT CONTROL [Schulz]: 'PUSH_REPLY,route-gateway dhcp,ping 15,ping-restart 60' (status=1)
    
     
  4. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Try unticking "DHCP" under "client pool" and setting up a range manually. The dhcp option is fairly new in OpenVPN and it doesn't seem to have all the bugs worked out of it.
     
  5. JoAllard

    JoAllard Networkin' Nut Member

    Thing is, what do I put as range?

    The server is 192.168.3.1 and the client is 192.168.7.1. Why can't the client just take its address?
     
  6. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Okay. You're problem is that you're using TAP with different subnets on each end of the site-to-site. You should either use the same subnet on each end or switch to TUN (recommended).

    You can use TAP with different subnets, but you end up with the downsides of TAP without any of the benefits. If you go that route, you need to be sure to untick "Server is on the same subnet" on the client and enter an unused range of IPs in the server subnet for Client Pool on the server.
     
  7. JoAllard

    JoAllard Networkin' Nut Member

    Okay, my networks are now on the same 10.0.0.0/8 subnet. The server router is 10.0.0.1 and the client is 10.0.0.2. I am still on a TAP.

    I put 10.0.0.200-10.0.0.215 as the VPN address pool. My client has been given 10.0.0.200. Now how do I bring both ends together? Why do I need a range? Who is going to assign the IPs to my client router's clients? In short, how is this going to work?
     
  8. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Any necessary address allocation will happen automatically. If you go with TAP on the same subnet, you'll want to tick "Client is on the same subnet". The firmware will then link everything together for you.

    However, TAP site-to-site really causes some complications. I would really recommend using TUN and separate subnets.
     
  9. JoAllard

    JoAllard Networkin' Nut Member

    Okay, but the VPN subnet/mask option confuses me. Why do we need this?
     
  10. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    By asking this question, I assume you're going with TUN. The subnet/netmask is for the VPN tunnel itself. It needs to be distinct from both the client and server LANs' subnets. This is so that routing can happen correctly.

    For an example: site A could have a subnet of 192.168.1.0/255.255.255.0, site B could have a subnet of 192.168.2.0/255.255.255.0, and the VPN could have a subnet of 10.8.0.0/255.255.255.0. Since the subnets are all distinct, there is no ambiguity on where traffic needs to go.

    If you fill in the client-specific options table on the server with the subnet of the client LAN (be careful to enter the CommonName exactly as it was when you created the client certificate) and untick the "Create NAT on tunnel" checkbox on the client, you will have complete communication between client and server LANs, and you'll never need to worry about the VPN subnet.
     
  11. JoAllard

    JoAllard Networkin' Nut Member

    The tunnel is working correctly, I assume, but I think my routing is all wrong. Site A has subnet 10.0.0.1/8 and site B is 10.0.2.1/8. The VPN tunnel is 10.254.0.1/8.

    Site A can ping site B with 10.254.0.6, but not with 10.0.2.1.
    Site B can ping site A with 10.0.0.1 and 10.254.0.1. It can not ping my laptop on site A on 10.0.0.104.
    Site A can ping my laptop just fine.

    Site A routing:
    Code:
    # route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.254.0.2      *               255.255.255.255 UH    0      0        0 tun21
    70.82.60.0      *               255.255.255.0   U     0      0        0 vlan1
    10.0.0.0        *               255.255.255.0   U     0      0        0 br0
    10.254.0.0      10.254.0.2      255.255.255.0   UG    0      0        0 tun21
    127.0.0.0       *               255.0.0.0       U     0      0        0 lo
    default         modemcable001.6 0.0.0.0         UG    0      0        0 vlan1
    
    Site B routing:
    Code:
    # route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.254.0.5      *               255.255.255.255 UH    0      0        0 tun0
    66.36.152.1     *               255.255.255.255 UH    0      0        0 ppp0
    66.36.152.1     *               255.255.255.255 UH    0      0        0 ppp0
    10.0.0.0        10.254.0.5      255.255.255.0   UG    0      0        0 tun0
    10.0.2.0        *               255.255.255.0   U     0      0        0 br0
    10.254.0.0      10.254.0.5      255.255.255.0   UG    0      0        0 tun0
    169.254.0.0     *               255.255.0.0     U     0      0        0 br0
    127.0.0.0       *               255.0.0.0       U     0      0        0 lo
    default         dsl-152-1.aei.c 0.0.0.0         UG    0      0        0 ppp0
    
    What do I have to fix and how?
     
  12. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    Did you fill out the client-specific options table like I mentioned? What you're seeing is as if you didn't.

    If you did, could you post the server logs from the period when the client connects?
     
  13. JoAllard

    JoAllard Networkin' Nut Member

    I thought I had to change these on the client. I did it on the server and it somewhat works. I still can't ping the PCs cross-tunnel. Why?
     
  14. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    It's hard to say without you providing the info I suggested.

    Also, it'd be helpful to describe what you mean by "somewhat works".
     
  15. JoAllard

    JoAllard Networkin' Nut Member

    Sorry for that. But as I only know ping to test stuff, I try to ping nodes back and forth. I'm saying it somewhat works because of mixed results in ping.

    10.0.0.1 (A) can ping 10.0.0.104 (A-me), but not 10.0.2.1 (B)
    10.0.2.1 (B) can ping 10.0.0.1 (A), 10.0.2.101 (B-PC), but not 10.0.0.104 (A-me)
    10.0.0.104 (A-me) can ping 10.0.0.1 (A), but not 10.0.2.1 (B) or 10.0.2.101 (B-PC)

    I (A-me) can ssh or http into router B, but I can't ping it.

    Here's a log:
    Code:
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: MULTI: multi_create_instance called
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Re-using SSL/TLS context
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: 66.36.156.108:2048 LZO compression initialized
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    Dec  8 14:59:38 ? daemon.notice openvpn[643]: 66.36.156.108:2048 TLS: Initial packet from 66.36.156.108:2048, sid=8cb0d064 01d0514f
    Dec  8 14:59:40 ? daemon.notice openvpn[643]: 66.36.156.108:2048 VERIFY OK: depth=1, /C=CA/ST=QC/[...]
    Dec  8 14:59:40 ? daemon.notice openvpn[643]: 66.36.156.108:2048 VERIFY OK: depth=0, /C=CA/ST=QC/[...]
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 Control Channel: TLSv1, cipher TLSv1/SSLv3 EDH-RSA-DES-CBC3-SHA, 1024 bit RSA
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: 66.36.156.108:2048 [Schulz] Peer Connection Initiated with 66.36.156.108:2048
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: MULTI: new connection by client 'Schulz' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to 
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: OPTIONS IMPORT: reading client specific options from: ccd/Schulz
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: MULTI: Learn: 10.254.0.6 -> Schulz/66.36.156.108:2048
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: MULTI: primary virtual IP for Schulz/66.36.156.108:2048: 10.254.0.6
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: MULTI: internal route 10.0.2.0/24 -> Schulz/66.36.156.108:2048
    Dec  8 14:59:41 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.0/24 -> Schulz/66.36.156.108:2048
    Dec  8 14:59:43 ? daemon.notice openvpn[643]: Schulz/66.36.156.108:2048 PUSH: Received control message: 'PUSH_REQUEST'
    Dec  8 14:59:43 ? daemon.notice openvpn[643]: Schulz/66.36.156.108:2048 SENT CONTROL [Schulz]: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,route 10.254.0.0 255.255.255.0,topology net30,ping 15,ping-restart 60,ifconfig 10.254.0.6 10.254.0.5' (status=1)
    Dec  8 15:00:01 ? syslog.info root: -- MARK --
    Dec  8 15:01:22 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.1 -> Schulz/66.36.156.108:2048
    Dec  8 15:04:40 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.1 -> Schulz/66.36.156.108:2048
    Dec  8 15:12:03 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.1 -> Schulz/66.36.156.108:2048
    Dec  8 15:12:12 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.101 -> Schulz/66.36.156.108:2048
    Dec  8 15:12:42 ? authpriv.info dropbear[716]: Child connection from 10.0.0.104:53763
    Dec  8 15:12:46 ? authpriv.notice dropbear[716]: pubkey auth succeeded for 'root' with key md5 3a:95:09:e1:83:83:13:66:05:38:25:8f:d0:7a:92:42 from 10.0.0.104:53763
    Dec  8 15:14:46 ? daemon.notice openvpn[643]: MULTI: Learn: 10.0.2.1 -> Schulz/66.36.156.108:2048
    Dec  8 15:27:02 ? daemon.info dnsmasq-dhcp[97]: DHCPINFORM(br0) 10.0.0.104 00:23:4d:49:69:68 
    Dec  8 15:27:02 ? daemon.info dnsmasq-dhcp[97]: DHCPACK(br0) 10.0.0.104 00:23:4d:49:69:68 Manhattan
    
    
    Note that site B is using DD-WRT. Is it supposed to work anyway, can I make changes or do I need to put Tomato?
     
  16. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    My guess is that your DD-WRT router has ping responses disabled (at least on this interface). If you can make any connection to it, VPN connectivity is there.

    As far as "A-me" not being able to connect over the tunnel: Is "A" the default gateway for "A-me" or there other devices involved? If "A" is not the default gateway for "A-me", you'll have to add a static route on "A" or "A-me" to get it working.
     
  17. JoAllard

    JoAllard Networkin' Nut Member

    Turns out, DD-WRT didn't make the necessary routing as did Tomato on the client side. What I did is to install Tomato on the client router and everything from there went fine. Thank you SgtPepper for your infinite patience and wisdom, I couldn't have done it without!
     

Share This Page