Error openvpn site to site not ping



  • Look,

    closed one vpn between two pfSense 2.2.2, I can ping on my side B pfSense to other machines on the side A.

    The error is when the affiliate machines (side B) can not ping the machine side A.

    The rules are released. both at headquarters and in branch.
    Using OpenVPN client in a season I can without problems.

    Side A - 192.168.10.0/24
    Side B - 192.168.2.0/24

    
    Side B - 192.168.2.0/24
    
    Internet:
    Destination        Gateway            Flags      Netif Expire
    default            200.XXX.90.XXX     UGS      pppoe0
    8.8.8.8            200.XXX.90.XXX     UGHS     pppoe0
    127.0.0.1          200.XXX.90.XXX     UGHS        lo0
    177.XX.189.XX      pppoe0             UHS      pppoe0
    177.XX .94.XX      link#7             UHS         lo0
    192.168.2.0/24     link#2             U           vr1
    192.168.2.1        link#2             UHS         lo0
    192.168.10.0/24    192.168.180.1      UGS      ovpnc2
    192.168.180.0/24   link#9             U        ovpnc2
    192.168.180.2      link#9             UHS         lo0
    192.168.200.0/24   link#8             U        ovpns1
    192.168.200.1      link#8             UHS         lo0
    200.XXX.90.XXX     link#7             UH       pppoe0
    





  • LAYER 8 Netgate

    Why TAP mode?



  • there is some problem for the site to site?


  • LAYER 8 Netgate

    Use tun.



  • You should normally use "tun" mode and there will be (at least) 3 subnets with different addresses and routing between them:
    a) Local LAN
    b) Tunnel subnet
    c) Remote LAN



  • modified. put to port 1195, tun, tcp ..
    network 192.168.181.0/24 to change with the other vpn client, the problem still remains, only Configo dripping from the pfSense .. the machines to hand Failure. however the log is okay.

    screens side B





  • LAYER 8 Netgate

    Why tcp?  Why are you doing things differently than every walkthrough and guide tells you to do?



  • changed too, made using udp and tcp and I could not, I can only ping the pfSense.

    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
            options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet 127.0.0.1 netmask 0xff000000
            inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
            nd6 options=21 <performnud,auto_linklocal>enc0: flags=0<> metric 0 mtu 1536
            nd6 options=21 <performnud,auto_linklocal>pppoe0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
            inet 189.XXX.XXX.205 --> 200.XXX.XXX.117 netmask 0xffffffff
            inet6 fe80::20d:b9ff:fe1a:4a54%pppoe0 prefixlen 64 scopeid 0x7
            nd6 options=21 <performnud,auto_linklocal>ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::20d:b9ff:fe1a:4a54%ovpns1 prefixlen 64 scopeid 0x8
            inet 192.168.200.1 --> 192.168.200.2 netmask 0xffffffff
            nd6 options=21 <performnud,auto_linklocal>Opened by PID 23881
    ovpnc2: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            options=80000 <linkstate>inet6 fe80::20d:b9ff:fe1a:4a54%ovpnc2 prefixlen 64 scopeid 0x9
            inet 192.168.181.6 --> 192.168.181.5 netmask 0xffffffff
            nd6 options=21 <performnud,auto_linklocal>Opened by PID 19975
    tap1: flags=8842 <broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=80000 <linkstate>ether 00:bd:49:3d:07:01
            nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
            status: no carrier</performnud,auto_linklocal></linkstate></broadcast,running,simplex,multicast></performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></performnud,auto_linklocal></up,pointopoint,running,noarp,simplex,multicast></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast> 
    
    Internet:
    Destination        Gateway            Flags      Netif Expire
    default            200.XXX.XXX.117     UGS      pppoe0
    8.8.8.8            200.XXX.XXX.117     UGHS     pppoe0
    127.0.0.1          200.XXX.XXX.117     UGHS        lo0
    177.XXX.XXX.XXX     pppoe0             UHS      pppoe0
    189.XXX.XXX.XXX     link#7             UHS         lo0
    192.168.2.0/24     link#2             U           vr1
    192.168.2.1        link#2             UHS         lo0
    192.168.10.0/24    192.168.181.5      UGS      ovpnc2
    192.168.181.0/24   192.168.181.5      UGS      ovpnc2
    192.168.181.5      link#9             UH       ovpnc2
    192.168.181.6      link#9             UHS         lo0
    192.168.200.0/24   192.168.200.2      UGS      ovpns1
    192.168.200.1      link#8             UHS         lo0
    192.168.200.2      link#8             UH       ovpns1
    200.XXX.XXX.XXX     link#7             UH       pppoe0
    
    


  • There is not an obvious problem there. Post the OpenVPN server settings at the other end and also the firewall rules on LAN and OpenVPN at each end.
    Try traceroute between clients at each end and see where it stops, or if it starts going out some WAN - that will give you a clue about where things go wrong.



  • follows the server screen .. site A




  • At minimum, you should specify the Site B subnet in the Site A "IPv4 Remote Network/s" box.

    You need to let the server know it will be routing traffic for 192.168.2.0/24 through the OpenVPN conx.

    Post the Site B Client screen as well to make sure nothing else is missing.



  • Site B Client screen



  • LAYER 8 Netgate

    As has been said, you have no remote networks specified at either end.  That's how pfSense knows what traffic to route over the tunnel.



  • Apr 19 16:10:49	openvpn[78509]: Closing TUN/TAP interface
    Apr 19 16:10:49	openvpn[78509]: /usr/local/sbin/ovpn-linkdown ovpnc2 1500 1558 192.168.181.6 192.168.181.5 init
    Apr 19 16:10:51	openvpn[78509]: ROUTE_GATEWAY 200.XXX.90.XXX
    Apr 19 16:10:51	openvpn[78509]: TUN/TAP device ovpnc2 exists previously, keep at program end
    Apr 19 16:10:51	openvpn[78509]: TUN/TAP device /dev/tun2 opened
    Apr 19 16:10:51	openvpn[78509]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
    Apr 19 16:10:51	openvpn[78509]: /sbin/ifconfig ovpnc2 192.168.181.10 192.168.181.9 mtu 1500 netmask 255.255.255.255 up
    Apr 19 16:10:51	openvpn[78509]: /usr/local/sbin/ovpn-linkup ovpnc2 1500 1558 192.168.181.10 192.168.181.9 init
    Apr 19 16:10:51	openvpn[78509]: /sbin/route add -net 192.168.10.0 192.168.181.9 255.255.255.0
    Apr 19 16:10:51	openvpn[78509]: /sbin/route add -net 192.168.10.0 192.168.181.9 255.255.255.0
    Apr 19 16:10:51	openvpn[78509]: ERROR: FreeBSD route add command failed: external program exited with error status: 1
    Apr 19 16:10:51	openvpn[78509]: /sbin/route add -net 192.168.181.1 192.168.181.9 255.255.255.255
    Apr 19 16:10:51	openvpn[78509]: Initialization Sequence Completed
    

  • LAYER 8 Netgate

    You need 192.168.2.0/24 in the remote networks on the server.  I believe you also need to put the 192.168.181.0/24 tunnel network in the client side.



  • was placed and not solved .. I will do with pfSense 2.1.5 for testing


  • LAYER 8 Netgate

    Are you certain the remote hosts will respond to pings from foreign networks?  This is often the firewalls on the destination hosts.  What version are you using?  There have been few problems with OpenVPN on 2.2, 2.2.1, and 2.2.2.  No reason to change versions.  All you have to do is configure it correctly.



  • pfsense 2.2.2



  • placed in the test environment (XenServer) two pfSense 2.1.5 doing via vpn openvpn. and it worked, same configuration. Will install version 2.2.2.



  • I have plenty of OpenVPN site-to-site links on 2.2.2 and they work fine just like they did in 2.1.5 - put the right subnets in Tunel, Local and Remote Network/s boxes on server and client, make sure the firewall rules on LAN and OpenVPN at both ends allow the relevant traffic - that is all there is to it.
    When I setup a new office it takes only a couple of minutes to bring up OpenVPN site-to-site links back to our main offices, it really does work.


Log in to reply