Configuring site-to-site VPN and Roadwarrior VPN for network with existing DHCP



  • I've got two pfsense boxes up and running, with roadwarrior OpenVPN access to either and also site-to-site OpenVPN between them.

    On network A, pfsense provides DHCP service to the LAN. RoadWarrior OpenVPN Clients can connect to Network A and can ping any LANside host.

    On network B, pfsense does NOT provide DHCP service to the LAN (there's an existing DHCP server there). RoadWarrior OpenVPN clients can connect to Network B, but are only able to ping the pfsense LAN address.

    As regards the site-to-site, if I SSH onto the network A pfsense box I CAN ping the network B LANside address, but no other LANside hosts on network A.

    If I SSH onto the network B pfsense box, I can't ping the Network A pfsense LANside address.

    Clearly I've got to add a route on the network A pfsense box which will route LAN-destined packets to the existing network A DHCP server (which is also the LAN router). How?

    I'm not sure what the issue with the site-to-site is though. The pfsense box on network A is configured as the OpenVPN server for the site-to-site. The pfsense box on network B is configured as the OpenVPN client for the site-to-site.

    Thanks in advance.

    Mezza



  • Could you provide a diagramm on how your network is setup and from where to where you can ping?

    not sure if it helps but:
    http://forum.pfsense.org/index.php/topic,7001.0.html
    http://forum.pfsense.org/index.php/topic,7457.0.html

    also if you want to do something that does not work out of the box with pfSense you might want to take a look at the man pages on http://www.openvpn.net
    and look for a command with which you can accomplish your goal.



  • Thanks for the reply. I had a look at the link, but don't see any applicable solutions.

    I've attached a network diagram, and here's a summary of the pings that work:

    | Source | Destination | Result |
    | pfSense B | 192.168.254.203 | Success |
    | pfSense B | Network A LAN | Timeout |
    | pfSense A | 192.168.0.1 | Timeout |
    | pfSense A | Network B LAN | Timeout |
    | RoadWarrior client | 192.168.0.1 | Success |
    | RoadWarrior client | 192.168.254.203 | Success |
    | RoadWarrior client | Network B Lan | Success |
    | RoadWarrior client | Network A Lan | Timeout |

    The wierd thing is that I tested both pfSense boxes with site-to-site and roadwarrior before on-site installs and everything worked as long as the pfSense boxes are the DHCP servers for the respective LANs.

    Hope this sheds more light.




  • One thing that jumps right to the eye:

    Did you create a static route on your 192.168.254.200/24 router
    that points for Network B to 192.168.254.203/24 ?
    Since all clients in Network A have this router as GW they dont even know that a Network B exists.

    Could you also provide the config-files for both roadwarrior servers?
    I suspect you forgot to push a route or two.
    Since the clients access the network on the other side of the site-to-site over the VPN you need to push a route to this  subnet too.

    What i'm really curious is why you cannot ping from pfSense A to 192.168.0.1.
    When the tunnel is up that should work.
    could you check the routing table after the tunnel is up?
    or could you provide the config files for site-to-site server and site-to-site client? maybe something got forgotten.

    @http://forum.pfsense.org/index.php/topic:

    The config files for the OpenVPN servers and clients are saved in the path /var/etc/



  • Hi again,

    I completely agree that the Network A clients (on the separate router and DHCP server) have no idea of Network B, but TBH I'm far more concerned why I can't ping pfSense B from pfSense A! :-) I also have NOT specified any additional routes at all, since in my lab tests OpenVPN seemed to be fine at automatically generating and pushing out the relevant routes. Admittedly, the lab tests were done with both pfSense boxes acting as local DHCP servers and routers.

    Here are the vpn configs:

    pfSense B

    Site-to-site client
    #user nobody
    #group nobody
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    dev tun
    proto tcp-client
    cipher BF-CBC
    up /etc/rc.filter_configure
    down /etc/rc.filter_configure
    remote 194.XXX.XXX.253 1195
    lport 1194
    ifconfig 192.168.0.2 192.168.0.1
    route 192.168.254.0 255.255.255.0
    secret /var/etc/openvpn_client0.secret
    comp-lzo

    RoadWarrior Server
    writepid /var/run/openvpn_server0.pid
    #user nobody
    #group nobody
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    dev tun
    proto udp
    cipher AES-128-CBC
    up /etc/rc.filter_configure
    down /etc/rc.filter_configure
    client-to-client
    server 10.0.10.0 255.255.255.0
    client-config-dir /var/etc/openvpn_csc
    push "route 192.168.0.0 255.255.255.0"
    lport 1194
    ca /var/etc/openvpn_server0.ca
    cert /var/etc/openvpn_server0.cert
    key /var/etc/openvpn_server0.key
    dh /var/etc/openvpn_server0.dh
    comp-lzo
    persist-remote-ip
    float

    pfSense A

    Site-to-site 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
    ifconfig 10.0.30.1 10.0.30.2
    lport 1195
    route 192.168.0.0 255.255.255.0
    secret /var/etc/openvpn_server1.secret
    comp-lzo
    persist-remote-ip
    float

    RoadWarrior Server
    writepid /var/run/openvpn_server0.pid
    #user nobody
    #group nobody
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    dev tun
    proto tcp-server
    cipher AES-128-CBC
    up /etc/rc.filter_configure
    down /etc/rc.filter_configure
    client-to-client
    server 10.0.20.0 255.255.255.0
    client-config-dir /var/etc/openvpn_csc
    push "route 192.168.254.0 255.255.255.0"
    lport 1196
    ca /var/etc/openvpn_server0.ca
    cert /var/etc/openvpn_server0.cert
    key /var/etc/openvpn_server0.key
    dh /var/etc/openvpn_server0.dh
    comp-lzo
    persist-remote-ip
    float

    I had originally set up all VPNs to use UDP, but I've changed the VPNs on pfSenseA to use TCP since I thought at one stage that it might be a routing issue with UDP. Either way, it's clear all VPNs are correctly being setup, just the routing that's problematic.

    TIA,

    Mezza



  • Just a brief update for any interested parties.

    I solved the problems with access to Network A (whether for RoadWarriors or the Site to site with Network B) by simply adding static routes to my existing router on network A at 192.168.254.200, namely:

    10.0.20.0/255.255.255.0 -> 192.168.254.203
    10.0.30.0/255.255.255.0 -> 192.168.254.203
    192.168.0.0/255.255.255.0 -> 192.168.254.203

    I did NOT have to open up any firewall rules, as from my understanding OpenVPN generates automatic filters anyway. The only manually created firewall rules I have are those to allow WAN SSH connections, and those to allow incoming WAN OpenVPN connections.

    So, at this stage in time:

    • I can ping from pfSense B -> pfSense A

    • I can ping from pfSense B -> Network A LAN computers

    • I can ping from Network B LAN computers -> Network A LAN computers

    • I can ping from Network B LAN computers -> pfSense A

    • I can ping from Network A LAN computers -> Network B LAN computers

    • I can ping from Network A LAN computers -> pfSense B

    BUT I'm unable to ping from pfSense A -> pfSense B or pfSense A -> Network B LAN computers.

    What am I missing?



    • I can ping from Network A LAN computers -> Network B LAN computers
      BUT I'm unable to ping from pfSense A -> pfSense B or pfSense A -> Network B LAN computers.

    This is really strange
    Especially since you
    can ping from the "pfSense A subnet" to the "pfSense B subnet"
    but
    not from "pfSense A" to "pfSense B subnet"

    But pfSense does not add filter rules automatically.
    It only adds routes automatically.
    But the tap interface should not be firewalled….

    What does the routing table on the two pfSense's look like?



  • Hi again,

    Here are the IP4 routes from netstat -nrW:

    pfsense A
    Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
    default            194.XXX.XXX.253    UGS        0  168620  1500      vr1
    10.0.20/24        10.0.20.2          UGS        0    20300  1500    tun0
    10.0.20.2          10.0.20.1          UH          1        0  1500    tun0
    10.0.30.2          10.0.30.1          UH          1        0  1500    tun1
    127.0.0.1          127.0.0.1          UH          0        1  16384      lo0
    192.168.0          10.0.30.2          UGS        0  107810  1500    tun1
    192.168.254        link#1            UC          0        0  1500      vr0
    192.168.254.204    00:0d:93:9d:fd:3a  UHLW        1      392  1500      vr0    702
    192.168.254.240    00:16:cb:a9:e8:67  UHLW        1      43  1500      vr0    437
    194.XXX.XXX.224/27  link#2            UC          0        0  1500      vr1
    194.XXX.XXX.225    00:XX:XX:XX:XX:de  UHLW        1      19  1500      vr1    93
    194.XXX.XXX.227    00:XX:XX:XX:XX:de  UHLW        1        0  1500      vr1    98
    194.XXX.XXX.254    00:XX:XX:XX:XX:0b  UHLW        2    5955  1500      vr1  1189

    pfSense B
    Destination        Gateway            Flags    Refs      Use    Mtu    Netif Expire
    default            220.XXX.XXX.241      UGS        0    81874  1500      vr1
    127.0.0.1          127.0.0.1          UH          0        0  16384      lo0
    192.168.0          link#1            UC          0        0  1500      vr0
    192.168.0.1        192.168.0.2        UH          1        0  1500    tun0
    192.168.0.193      00:16:36:53:c8:64  UHLW        1    5963  1500      vr0  1187
    192.168.0.232      00:19:d1:61:a3:aa  UHLW        1    10363  1500      vr0    939
    192.168.0.233      00:14:2a:8a:1e:42  UHLW        1    7065  1500      vr0  1149
    192.168.0.234      00:14:85:5e:9a:de  UHLW        1    6628  1500      vr0  1144
    192.168.0.236      00:08:a1:92:31:94  UHLW        1    1826  1500      vr0  1140
    192.168.0.237      00:11:5b:f4:1d:ff  UHLW        1    1010  1500      vr0  1200
    192.168.0.238      00:16:76:c5:51:e0  UHLW        1    4272  1500      vr0  1145
    192.168.0.239      00:19:d1:ee:1e:6a  UHLW        1    2951  1500      vr0  1179
    192.168.0.240      00:14:2a:8b:7b:b1  UHLW        1    8819  1500      vr0  1188
    192.168.0.241      00:11:5b:f4:26:4e  UHLW        1      845  1500      vr0  1198
    192.168.0.242      00:14:2a:08:8f:56  UHLW        1      331  1500      vr0    797
    192.168.0.243      00:16:76:c5:58:61  UHLW        1    4768  1500      vr0  1101
    192.168.0.244      00:14:2a:8b:79:df  UHLW        1    1715  1500      vr0  1156
    192.168.254        192.168.0.1        UGS        0        0  1500    tun0
    220.XXX.XXX.240/29  link#2            UC          0        0  1500      vr1
    220.XXX.XXX.241      XX:XX:XX:XX:XX:1f  UHLW        2    3755  1500      vr1  1174

    I've obviously changed the external IP addresses, but the important information is still there.

    BTW, aside from not being able to ping anything on network B from pfSense A, everything else is working fine in terms of cross-network access to internal servers and VoIP systems. Consequently, although I'm academically interested to know what the issue is, please don't bust a gut on this.

    Thanks again.


Log in to reply