Incorrect routing to some public IP addresses due to OpenVPN tunnel.



  • Hi folks, I'm facing a pesky problem with pfSenses's OpenVPN service and I'm unfortunately forced to ask wiser and skilled people here. The problem is that some IP addresses do not route to WAN interface (rl0), but they goes to the a virtual one (tap0). For example google's 74.125.79.104 and 74.125.79.17, ubuntuforums.org, or few others. My OpenVPN configuration uses bridging method, client to client communication - the network topology is like: LAN <–> router <--> (INTERNET) <--> clients (they connects from 4 different locations). Clients acquire IP address of LAN (192.168.16.0/24), using 10.0.10.0/24 address pool and are able to comunicate with each other (and PCs in LAN) with no problem. I'm able to connect mentioned IP addresses only when I disable OpenVPN server. When I ssh to pfSense router, I can see few this:

    # arp -a
    ey-in-f104.google.com (74.125.79.104) at (incomplete) on tap0 [ethernet]
    ? (192.168.16.3) at 00:07:e9:79:xx:xx on rl0 [ethernet]
    ? (192.168.16.4) at 00:18:f3:ac:xx:xx on rl0 [ethernet]
    ? (192.168.16.35) at 00:22:15:46:xx:xx on rl0 [ethernet]
    ? (192.168.16.41) at 00:00:00:00:xx:xx on rl0 [ethernet]
    ? (192.168.16.47) at 00:1d:60:db:xx:xx on rl0 [ethernet]
    … # there is more computers in LAN
    ? (213.194.x.y) at 00:e0:b6:12:d4:ac on xl0 [ethernet] # ISP's router
    
    # netstat -rn
    Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            213.194.x.y     UGS         0 77122488    xl0
    10.0.10.0&0xa000a02 link#10            UC          0     9080   tap0
    74.125.79.104      link#10            UHLW        1        0   tap0
    127.0.0.1          127.0.0.1          UH          0        0    lo0
    192.168.16.0/24    link#1             UC          0   115823    rl0
    192.168.16.3       00:07:e9:79:xx:xx  UHLW        1       18    rl0    832
    192.168.16.4       00:18:f3:ac:xx:xx  UHLW        1  2059216    rl0   1190
    192.168.16.35      00:22:15:46:xx:xx  UHLW        1   901536    rl0   1166
    192.168.16.41      00:00:00:00:xx:xx  UHLW        1    22487    rl0   1013
    192.168.16.47      00:1d:60:db:xx:xx  UHLW        1    30916    rl0   1181
    …
    213.194.x.z/29  link#2             UC          0        0    xl0 # ISP's network
    213.194.x.y    00:e0:b6:12:xx:xx  UHLW        2   193535    xl0   1198 # ISP's router
    213.194.x.x     213.194.x.x     UH          0        0  carp0 # our router (dst+gw addresses are both the same)
    

    There are my configuration files:

    Server:

    writepid /var/run/openvpn_server1.pid
    #user nobody
    #group nobody
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    dev tun
    proto tcp-server
    cipher BF-CBC
    up /etc/rc.filter_configure
    down /etc/rc.filter_configure
    tls-server
    ifconfig 10.0.10.1 10.0.10.2
    push "route 192.168.16.0 255.255.255.0"
    lport 1194
    push "dhcp-option DNS 192.168.16.1"
    push "dhcp-option WINS 192.168.16.4"
    push "dhcp-option NBT 4"
    ca /var/etc/openvpn_server1.ca
    cert /var/etc/openvpn_server1.cert
    key /var/etc/openvpn_server1.key
    dh /var/etc/openvpn_server1.dh
    comp-lzo
    persist-remote-ip
    float
    dev tap0
     float
     server-bridge 192.168.16.1 255.255.255.0 192.168.16.61 192.168.16.254
    

    Client:

    port 1194
    dev tap
    dev-node ovpn-tun0
    proto tcp-client
    remote 213.194.x.x 1194
    ping 30
    
    persist-tun
    persist-key
    
    tls-client
    ca C:\\Program\ Files\\OpenVPN\\config\\ca.crt
    cert C:\\Program\ Files\\OpenVPN\\config\\client1.crt
    key C:\\Program\ Files\\OpenVPN\\config\\client1.key
    
    ns-cert-type server
    comp-lzo
    pull
    

    I am also attaching two files from Wireshark scan - first for working google IP address, second for not working (in both cases it's only SYN packet, because nothing more is sent in case of bad routing), but I don't know if there is something helpful in them (I thing not - but maybe I'm wrong). I beleve the problem is not in TCP connection method, coz I tried to switch TCP to UDP (despite of clients configuration stay unchanged) and it not helped at all. If you'll want to know anything else, just say me please. I'll be glad for every suggestion. Thx. ;)
    google-working.txt
    google-notworking.txt


Locked