Routing problem on site-to-site connection



  • I have two sites connected with OpeVPN below, Site A and Site B can successfully access each other internal network. Site B directly connects to Site C, and can access Site C also. Site A need to access Site C, but cannot. It seems the IP cannot be translated successfully, please see the ping results.  Do you have any ideas what's wrong? Thanks.

    Site A (192.168.0.0/24) –--- <openvpn site="" to="">------ Site B (192.168.1.0/24) ----<192.168.51.2>--<192.168.51.1>-- Site C ( 10.0.0.0/8)

    Site A: 
    (Server.Advanced)
    route 10.0.0.0 255.0.0.0;
    route 192.168.0.0 255.255.248.0;
    push "route 192.168.0.0 255.255.255.0";

    (Client Specific Overrides.Advanced)
    iroute 192.168.1.0 255.255.255.0;
    iroute 10.0.0.0 255.0.0.0;

    Ping results captured on Site B port connected to Site C:

    From Site A:
    3 0.617589 192.168.0.129 10.1.8.5 ICMP 74 Echo (ping) request  id=0x0001, seq=1057/8452, ttl=126 (no response found!)

    From Site B:
    1 0.000000 192.168.51.2 10.1.8.5 ICMP 74 Echo (ping) request  id=0xe9d2, seq=24864/8289, ttl=128 (reply in 2)
    2 0.058736 10.1.8.5 192.168.51.2 ICMP 74 Echo (ping) reply    id=0xe9d2, seq=24864/8289, ttl=116 (request in 1)</openvpn>



  • Please clarify your setup.  Your network map suggests your sites are daisy chained and Site B is the router between A and C.  Or is Site A the hub and has two separate tunnels… one to A and one to C?

    Post your server and clients config files from each site.

    You can actually do this without iroutes btw, but having not seen your configs yet there most likely are two different scenarios at play:

    • If your sites are daisy chained like your network map suggests (A<->B<->C) and you're using iroutes then your server config should be on Site B (not A) and you will need return routes on A for C and on C for A.

    • If Site A is your HUB with two separate tunnels to B and C, then most likely you have the iroute to 10.0.0.0/8 located on the wrong tunnel.



  • Site A [WAN] –-<openvpn site="" to="">--- [WAN] Site B [OPT1:192.168.51.2] –-[GW192.168.51.1]–-<routers>--- Site C
          [LAN]                                                          [LAN]                                                                                        [LAN]
            |                                                                  |                                                                                              |
            |                                                                  |                                                                                              |
    (192.168.0.0/24)                                        (192.168.1.0/24)                                                                          (10.0.0.0/8)

    Site A is openvpn server, connected by other client sites.

    Site B is client site, and it has a static IP to connect to Site C at OPT1.

    Site B: Static Route
              Destination Gateway Flags Refs Use Mtu Netif
              10.0.0.0/8 192.168.51.1 UGS 0 682310 1500 em1

    Site C is not a openvpn client site, it connects to Site B through a lan.

    Site A :

    Server1.conf:
    dev ovpns1
    verb 1
    dev-type tun
    dev-node /dev/tun1
    writepid /var/run/openvpn_server1.pid
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    auth SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 23.255.13.38
    tls-server
    server 192.168.100.0 255.255.255.0
    client-config-dir /var/etc/openvpn-csc
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'server' 1"
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    max-clients 10
    push "route 192.168.0.0 255.255.255.0"
    client-to-client
    ca /var/etc/openvpn/server1.ca
    cert /var/etc/openvpn/server1.cert
    key /var/etc/openvpn/server1.key
    dh /etc/dh-parameters.1024
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    persist-remote-ip
    float
    route 10.0.0.0 255.0.0.0
    route 192.168.0.0 255.255.248.0
    push "route 192.168.0.0 255.255.248.0"

    /var/etc/openvpn-csc/client1
    iroute 192.168.1.0 255.255.255.0
    iroute 10.0.0.0 255.0.0.0

    Site B:

    dev-type tun
    tun-ipv6
    dev-node /dev/tun1
    writepid /var/run/openvpn_client1.pid
    #user nobody
    #group nobody
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    proto udp
    cipher AES-128-CBC
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    local 118.120.180.38
    tls-client
    client
    lport 0
    management /var/etc/openvpn/client1.sock unix
    remote 23.255.13.38 1194
    ca /var/etc/openvpn/client1.ca
    cert /var/etc/openvpn/client1.cert
    key /var/etc/openvpn/client1.key
    tls-auth /var/etc/openvpn/client1.tls-auth 1
    comp-lzo</routers></openvpn>



  • route 192.168.0.0 255.255.248.0
    push "route 192.168.0.0 255.255.248.0"
    

    That looks a bit odd, teling each end that 192.168.0.0/21 is reachable at the other end of the OpenVPN link. But actually pfSense routing is smart enough to to also know about and deliver directly to the local LAN at siteA and siteB, not ping-pong traffic between the 2.

    I suspect that the router at site C does not have a route back to site A LAN 192.168.0.0/24, or site C router has a firewall that is blocking that, or site B OPT1 has firewall rule/s that do not allow that…



  • Thanks for all, I found the solution from below

    https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1

    I added a rule to translate IP (192.168.0.0/24) to 192.168.51.2, it's working well now.

    [NAT OUTBOUND Rule]
    Interface: OPT1
    Protocol: any
    Source: 192.168.0.0/24
    Destination: any
    Translation: interface address



  • That shows that there is a device somewhere that does not have a route back to 192.168.0.0/24 or is blocking that traffic. Hiding it behind 192.168.51.2 is one way to work around that.



  • It's already been said, but yes, the edge device @ site C needs a route back to 192.168.0.0/21 thru 192.168.51.2.

    A few things:

    • Your iroutes are redundant as you are already routing (and pushing) the appropriate routes thru the tunnel.

    • Remove "route 192.168.0.0 255.255.248.0" from Site A's config.  This directive is for the remote subnet, not local

    • Your NAT works, but now removes your ability to monitor, isolate and firewall connections coming from Site A on Site C.  This may or may not be an issue depending on your priorities and security concerns



  • The edge device is not my own equipment at Site C, so I can't change anything on it.

    In my 1st post, you can see the source IP of ICMP has been traslated to 192.168.51.2 from Site B 192.168.1.0/24 on OPT1, but through the vpn it still kept the same to pass to Site C, therefore it can't return back from Site C. Is it a bug or nromal ?



  • It is normal - whatever address you NAT the site A subnet to, that needs to be an address that site C knows how to route back to. So you probably might want it to be some address in site B, which site C already knows how to reach.