Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm trying to openvpn into an office network (192.168.1.0/24) from a client sitting on a network with the same subnet (also 192.168.1.0/24). It is a linux (ubuntu 9.10) server and windows client.

I followed this ubuntu openvpn community documentation guide and from what I can tell the base connection works fine. Of course I get a bunch of error/warnings about ip address collisions.

I was then trying to follow this guide on 'Dirty NAT tricks to get a VPN to work with clients also numbered in the private address space' but have not been successful. While I have a theoretical understanding of routing/masquerading I have relatively little practical experience and am unsure what is wrong.

Thus far, I have gotten to the point where the client connects to the server and is assigned an IP 10.22.8.10. However I am unable to ping the server ip 10.22.8.1 like the documentation suggests I should be able to.

The server config is basically identical to guide 1 with the modifications from guide 2, i.e. setting the 'server-bridge 10.22.8.1 255.255.255.0 10.22.8.10 10.22.8.120' and 'push "route 10.22.0.0 255.255.0.0 10.22.8.1"'. In addition I add the tap interface configuration commands to up.sh.

The client config remains the same as guide 1.

Server 'ifconfig tap0' (edit: sorry if this looks screwy. In the preview pane of editing this post it looks fine)

tap0 Link encap:Ethernet HWaddr ee:ee:a8:04:8a:fc inet addr:10.22.8.1 Bcast:0.0.0.0 Mask:255.255.255.0 inet6 addr: fe80::ecee:a8ff:fe04:8afc/64 Scope:Link UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:610 errors:0 dropped:0 overruns:0 frame:0 TX packets:4533 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:111341 (111.3 KB) TX bytes:650830 (650.8 KB)

The client log on connection:

  Mon Mar 01 00:30:13 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009  
    Mon Mar 01 00:30:13 2010 WARNING: No server certificate verification method has been enabled.  See URL-REDACTED for more info.
    Mon Mar 01 00:30:13 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    Mon Mar 01 00:30:13 2010 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
    Mon Mar 01 00:30:13 2010 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 00:30:13 2010 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 00:30:13 2010 LZO compression initialized
    Mon Mar 01 00:30:13 2010 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
    Mon Mar 01 00:30:13 2010 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
    Mon Mar 01 00:30:13 2010 Local Options hash (VER=V4): '13a273ba'
    Mon Mar 01 00:30:13 2010 Expected Remote Options hash (VER=V4): '360696c5'
    Mon Mar 01 00:30:13 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
    Mon Mar 01 00:30:13 2010 UDPv4 link local: [undef]
    Mon Mar 01 00:30:13 2010 UDPv4 link remote: REDACTED:1194
    Mon Mar 01 00:30:13 2010 TLS: Initial packet from REDACTED:1194, sid=11055cf2 cc0d1ea0
    Mon Mar 01 00:30:14 2010 VERIFY OK: depth=1, REDACTED
    Mon Mar 01 00:30:14 2010 VERIFY OK: depth=0, REDACTED
    Mon Mar 01 00:30:14 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 01 00:30:14 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 00:30:14 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 01 00:30:14 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 00:30:14 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
    Mon Mar 01 00:30:14 2010 [server] Peer Connection Initiated with REDACTED:1194
    Mon Mar 01 00:30:17 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
    Mon Mar 01 00:30:17 2010 PUSH: Received control message: 'PUSH_REPLY,route 10.22.0.0 255.255.0.0 10.22.8.1,route-gateway 10.22.8.1,ping 10,ping-restart 120,ifconfig 10.22.8.10 255.255.255.0'
    Mon Mar 01 00:30:17 2010 OPTIONS IMPORT: timers and/or timeouts modified
    Mon Mar 01 00:30:17 2010 OPTIONS IMPORT: --ifconfig/up options modified
    Mon Mar 01 00:30:17 2010 OPTIONS IMPORT: route options modified
    Mon Mar 01 00:30:17 2010 OPTIONS IMPORT: route-related options modified
    Mon Mar 01 00:30:17 2010 ROUTE default_gateway=192.168.1.254
    Mon Mar 01 00:30:17 2010 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{7464875E-98E9-46AF-8F86-69FF32FFB722}.tap
    Mon Mar 01 00:30:17 2010 TAP-Win32 Driver Version 9.6 
    Mon Mar 01 00:30:17 2010 TAP-Win32 MTU=1500
    Mon Mar 01 00:30:17 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.22.8.10/255.255.255.0 on interface {7464875E-98E9-46AF-8F86-69FF32FFB722} [DHCP-serv: 10.22.8.0, lease-time: 31536000]
    Mon Mar 01 00:30:17 2010 Successful ARP Flush on interface [33] {7464875E-98E9-46AF-8F86-69FF32FFB722}
    Mon Mar 01 00:30:22 2010 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
    Mon Mar 01 00:30:22 2010 C:\WINDOWS\system32\route.exe ADD 10.22.0.0 MASK 255.255.0.0 10.22.8.1
    Mon Mar 01 00:30:22 2010 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
    Mon Mar 01 00:30:22 2010 Route addition via IPAPI succeeded [adaptive]
    Mon Mar 01 00:30:22 2010 Initialization Sequence Completed
    Mon Mar 01 01:30:14 2010 TLS: soft reset sec=0 bytes=648728/0 pkts=3922/0
    Mon Mar 01 01:30:14 2010 VERIFY OK: depth=1, REDACTED
    Mon Mar 01 01:30:14 2010 VERIFY OK: depth=0, REDACTED
    Mon Mar 01 01:30:15 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 01 01:30:15 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 01:30:15 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 01 01:30:15 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 01 01:30:15 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

The client route seems to be pushed ok (route print):

  Active Routes:
    Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.23     25
        10.22.0.0      255.255.0.0        10.22.8.1       10.22.8.10     30
        10.22.8.0    255.255.255.0         On-link        10.22.8.10    286
       10.22.8.10  255.255.255.255         On-link        10.22.8.10    286
      10.22.8.255  255.255.255.255         On-link        10.22.8.10    286
    ...

However when I try to get to 10.22.8.1 it still seems to want to hop out of my local internet connection:

  C:\Windows\system32>tracert 10.22.8.1
    Tracing route to 10.22.8.1 over a maximum of 30 hops
      1     1 ms     1 ms     1 ms  home.gateway [192.168.1.254]
      2  nexthop.qld.iinet.net.au [203.55.228.88]  reports: Destination net unreachable.

Can anybody advise me as to what I'm doing wrong (or alternatively, if there is an easy, more tenable way of doing what I want - note that as per solution #1 in guide 2, renaming either subnet is not possible)

share|improve this question
    
I think this is a very interesting question, and I wouldn't mind trying to replicate it – though I think it might be a bit problematic for me to create this scenario. Based on your route print, you're using something other than XP – Windows Vista or 7, maybe? Can you let me know so I can create the appropriate VM for testing? –  fission Mar 5 '10 at 10:03
    
@fission: I'm using Windows 7. If you are interested, I can probably try it on a Windows XP machine. Let me know if you want any further information. –  fostandy Mar 8 '10 at 12:10

2 Answers 2

Your default route metric value is lower than the 10.22.0.0/16 route and it gets routed to the default route. In resolving routes, if more than one route matches destination, the lower metric value route takes precedence.

Either push a default route through VPN or lower metric for 10.22.0.0/16 (increase metric for default route).

It should look like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
      0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.23    1000
    10.22.0.0      255.255.0.0        10.22.8.1       10.22.8.10     30
    10.22.8.0    255.255.255.0         On-link        10.22.8.10    286
   10.22.8.10  255.255.255.255         On-link        10.22.8.10    286
  10.22.8.255  255.255.255.255         On-link        10.22.8.10    286
share|improve this answer

What you need to do, is to remove the default route and add a route specific only to your VPN server and mark it available through your local router.

So, you should have 3 routes:

vpn.example.com   255.255.255.255 gw 192.168.1.254
192.168.1.0       255.255.255.0   gw 10.22.8.1
0.0.0.0           0.0.0.0         gw 10.22.8.1
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.