Chattanooga
Unix
Gnu
Android
Linux
Users
Group

 

Hot Topics:

Sponsoring:

site-to-site multi-lan openvpn routing

From: Matt Keys 
------------------------------------------------------
I'm hoping someone more familiar with openvpn advanced options can 
assist. I'm pretty sure it's a minor routing issue. I've tried to follow 
the setup instructions here : 
https://doc.pfsense.org/index.php/Routing

=============================================================== From: Benjamin Stewart ------------------------------------------------------ Site B is using for openvpn server options .. ipv4 tunnel network: 192.168.254.0/24 ipv4 local network/s : 192.168.20.0/24 ipv4 remote network/s: 172.16.1.0/24,172.16.2.0/24 under advanced I have "client-to-client" Site A is using for openvpn client options .. ipv4 tunnel network: 192.168.254.0/24 ipv4 remote network/s: 172.16.1.0/24,172.16.2.0/24 ------ If the above is true, then it seems you're telling both sites that the other has the 172.16.x.x networks. That's bound to confuse something! It might be helpful to see the routes from site A, as well.

=============================================================== From: Matt Keys ------------------------------------------------------ site a routes : default wanip1 UGS 0 4681131 1500 em0 wanip1.network/23 link#1 U 0 0 1500 em0 wanip1 link#1 UHS 0 0 16384 lo0 75.75.75.75 wanip1.gw UGHS 0 20244 1500 em0 75.75.76.76 wanip1.gw UGHS 0 20238 1500 em0 wanip2.gw link#13 UH 0 0 1492 pppoe0 wanip2 link#13 UHS 0 0 16384 lo0 127.0.0.1 link#8 UH 0 28677 16384 lo0 166.102.165.11 wanip2.gw UGHS 0 20152 1492 pppoe0 166.102.165.13 wanip2.gw UGHS 0 20149 1492 pppoe0 172.16.1.0/24 link#5 U 0 42 1500 em4 172.16.1.1 link#5 UHS 0 0 16384 lo0 172.16.2.0/24 link#6 U 0 4128 1500 em5 172.16.2.1 link#6 UHS 0 0 16384 lo0 192.168.1.0/24 link#2 U 0 7495548 1500 em1 192.168.1.1 link#2 UHS 0 0 16384 lo0 192.168.10.0/24 link#3 U 0 66559 1500 em2 192.168.10.1 link#3 UHS 0 16 16384 lo0 192.168.20.0/24 192.168.254.5 UGS 0 41483 1500 ovpnc1 192.168.254.0/24 192.168.254.5 UGS 0 3898 1500 ovpnc1 192.168.254.5 link#14 UH 0 0 1500 ovpnc1 192.168.254.6 link#14 UHS 0 0 16384 lo0 208.67.220.220 wanip1.gw UGHS 0 114003 1500 em0 208.67.222.222 wnaip2.gw UGHS 0 114000 1492 pppoe0

=============================================================== From: Benjamin Stewart ------------------------------------------------------ Nothing leaps out at me, there. Did you correct/verify your local/remote network configuration? 172.16.1.0/24,172.16.2.0/24 should be local to site A, remote to site B, correct?

=============================================================== From: Matt Keys ------------------------------------------------------ Yes, thanks for pointing that out! I changed site A client config to have .. ipv4 remote network/s: 192.168.20.0/24 Then restarted the service. Retesting, site A pfsense (client) can ping 192.168.20.2 (host in site b lan), but site b pfsense (server) still can't ping site A 172.16.1.1 or 172.16.2.1 (site a pfsense IP for em4 and em5). site b now has in diagnostics -> routes.. default wanip3.gw UGS 0 258596 1500 em0 8.8.4.4 wanip3.gw UGHS 0 6585 1500 em0 8.8.8.8 wanip3.gw UGHS 0 225761 1500 em0 127.0.0.1 link#5 UH 0 15003 16384 lo0 172.16.1.0/24 192.168.254.2 UGS 0 6 1500 ovpns1 172.16.2.0/24 192.168.254.2 UGS 0 0 1500 ovpns1 192.168.10.0/24 192.168.254.2 UGS 0 0 1500 ovpns1 192.168.20.0/24 link#2 U 0 37192 1500 re0 192.168.20.1 link#2 UHS 0 0 16384 lo0 192.168.30.0/24 192.168.254.2 UGS 0 0 1500 ovpns1 192.168.254.0/24 192.168.254.2 UGS 0 6 1500 ovpns1 192.168.254.1 link#8 UHS 0 0 16384 lo0 192.168.254.2 link#8 UH 0 0 1500 ovpns1 208.67.220.220 wanip3.gw UGHS 0 6572 1500 em0 208.67.222.222 wanip3.gw UGHS 0 6572 1500 em0 wanip3.network/29 link#1 U 0 1432860 1500 em0 wanip3 link#1 UHS 0 0 16384 lo0 site a now has in diagnostics -> routes .. default wanip1.gw UGS 0 4990656 1500 em0 wanip1.network/23 link#1 U 0 0 1500 em0 wanip1 link#1 UHS 0 0 16384 lo0 75.75.75.75 wanip1.gw UGHS 0 21125 1500 em0 75.75.76.76 wanip1.gw UGHS 0 21119 1500 em0 wanip2.gw link#13 UH 0 0 1492 pppoe0 wanip2 link#13 UHS 0 0 16384 lo0 127.0.0.1 link#8 UH 0 29732 16384 lo0 166.102.165.11 wanip2.gw UGHS 0 21031 1492 pppoe0 166.102.165.13 wanip2.gw UGHS 0 21028 1492 pppoe0 172.16.1.0/24 link#5 U 0 44 1500 em4 172.16.1.1 link#5 UHS 0 0 16384 lo0 172.16.2.0/24 link#6 U 0 6681 1500 em5 172.16.2.1 link#6 UHS 0 0 16384 lo0 192.168.1.0/24 link#2 U 0 8025424 1500 em1 192.168.1.1 link#2 UHS 0 0 16384 lo0 192.168.10.0/24 link#3 U 0 97475 1500 em2 192.168.10.1 link#3 UHS 0 16 16384 lo0 192.168.20.0/24 192.168.254.5 UGS 0 65 1500 ovpnc1 192.168.254.0/24 192.168.254.5 UGS 0 243 1500 ovpnc1 192.168.254.5 link#14 UH 0 0 1500 ovpnc1 192.168.254.6 link#14 UHS 0 0 16384 lo0 208.67.220.220 wanip1.gw UGHS 0 121177 1500 em0 208.67.222.222 wanip2.gw UGHS 0 121174 1492 pppoe0 Thanks again for your help, Matt

=============================================================== From: Benjamin Stewart ------------------------------------------------------ Those routes seem right, as far as I can tell at least. Where a firewall (or 2) is involved, it's always worth triple-checking your rules. Each firewall should know to allow traffic from each private subnet to talk to the others. Here are a few more shots in the dark: - Can PF-A ping 192.168.20.1? - Can 192.168.20.2 ping PF-A? - Use traceroute to find out how far the pings are making it. - If you have console access, try listening to interfaces along the path the pings should be taking with tcpdump -i [iface] - If it comes installed on PFSense these days, the pftop tool can show you which rules are incrementing their counters, live. Do pings increment counters for Pass rules? - Sometimes it helps to draw out a problem on your whiteboard.

=============================================================== From: Matt Keys ------------------------------------------------------ pf-a to 192.168.20.1 is good as well as .20.2 (host behind pf-b) PING 192.168.20.1 (192.168.20.1): 56 data bytes 64 bytes from 192.168.20.1: icmp

=============================================================== From: Benjamin Stewart ------------------------------------------------------ Sounds like the place to run a tcpdump/pftop is on PF-A. Good luck!

=============================================================== From: Dave Brockman ------------------------------------------------------ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I gave up on OpenVPN for L2L and/or Windows clients who need a semi-permanent connection. IPSec on pfsense is pretty brain-dead simple though. Regards, dtb - -- "Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network." RFC 1925 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTKJznAAoJEMP+wtEOVbcddm4H/j83MbqGJ9yqkhas7matim3p 3N7Jfyhz4rUYtakLBuFL1YIlSjUe4ZfJPv3wfTi/JPKHEvDGBelRj3akLyLeo/2Z OMIkpXzq/Wx95SxtPQ2zZtlLySakIFTndyggQeaFG49wuqnHSP1SJM5tW+2wgd3g VYjvt+dIYSZ35pXanXfLQGxNvOKDp7h46GZirfibH0M1Y65vWzlzaFQWHTK7gkFQ SK4et+6ScdonGpTWVEIFffQn3Cj/gOdX7fzgPB/hZs/eWplynr6njb5NSldcJHyH VM4tZaffCZGhK+9ohJGgD9khGMSu2GpKMKpT5M4I7Qsi3gcSbqXMkqB88o6zNG0= =Az6x -----END PGP SIGNATURE-----