Site to site ping with VLAN?
-
Hi,
I was wondering if someone could shed some light on what im trying to do. Currently i have a site to site working great, my question is on the client side of the site to site i need to be able to see one of the VLANS on the site 1.pfsense 192.168.3.254 site1--------openvpn--------pfsense 192.168.15.254 site 2
VLAN 60--------------------------openvpn-----------------need to be able to ping on VLAN60Now my question is on which site 1 or 2 would i create the rule? thats the part im confused about
Thank you
-
On the interface where the access comes into pfSense. It ever the same.
But in this case, you have to allow the access on both boxes, cause on both the traffic comes in. On the site 2 on the interface the client who wants to access VLAN60 is connected to (maybe LAN) and on site 1 on the OpenVPN interface. -
Thanks for the quick reply, so on the site 2 pfsense box i would create a rule from the LAN net to see traffic on VLAN 60?
Tutorials:
https://www.mediafire.com/folder/v329emaz1e9ih/Tutorials
-
Yes, if you don't still have the default any to any rule there.
-
VLANs are not passed over over the Internet. What you have to do is set up the routing so that traffic intended for the VLAN is routed appropriately. That means you need a route from site 2 to the VLAN on site 1, though that could be handled by the default route, if it's through the VPN to site 1.
-
Assuming the tunnel is routed, it's fairly straight forward, all you have to do is route the subnet assigned to VLAN 60 thru the tunnel and then verify that firewall rules exist to allow the traffic.
On site 2's config, add the subnet assigned to VLAN 60 to the IPv4 Remote network(s) section.
-
Thanks for the reply, so both site to site can ping each other, @viragomann i added the any to any rule on site 2 pfsense box on openvpn interface see picture
but still not getting it ping to the VLAN 60
this is the states from site 2 pfsense box
@JKnott thanks for the reply, if i understood correctly the routes would be any to any on openvpn? and route the LAN on the site 2 to the network in which i want to ping?
@marvosa thanks for the reply i kinda got lost so on site 1 pfsense on the vlan 60 route the network to the openvpn?
Thank you
-
On the site 2 pfSense you have to allow the access on LAN, since this is the interface which the packets come into the box. By default on LAN pfSense has a default to any rule already. So if you haven't deleted or restricted this rule, there is nothing to do.
On site 1 the packets come in on the OpenVPN interface, so on this box you have to set a rule on OpenVPN to allow the access.The routes are to be set in the OpenVPN settings by adding the remote network you want to reach to the "Remote Network/s".
On site 2 in the "IPv4 Remote Network/s" box you may have 192.168.3.0/24 (site 1 LAN) for now. Here you have to add the VLAN60 subnet. So for instance if VLAN60 is 192.168.60.0/24 you have to add the subnet this way:192.168.3.0/24,192.168.60.0/24On site 1 you have to put the LAN subnet of site 2 into the "IPv4 Remote Network/s", if it isn't already.
-
Thanks for the reply @viragomann, so i added what you said on site 2 the VLAN but cannot ping from pfSense site 2 to the LAN see picture
So this is my Site2 my LAN on site 1 is 192.168.3.0/22 and my VLAN which i need to ping is 192.168.60.0/24
And this is my Site 1 as my site 2 LAN is 192.168.15.0/24
Not sure what i missed?
Thank you
-
@killmasta93 said in Site to site ping with VLAN?:
my LAN on site 1 is 192.168.3.0/22
? Should be 192.168.0.0/22!
Maybe that confuses some clients.Try a ping from pfSense 2 to the LAN IP of pfSense 1. Try also a ping to the VLAN60 IP. If these pings work, change the source address to LAN and try again.
If all pings do fine try to ping devices behind pfSense 1. -
As @viragomann alluded to, if site 1's LAN interface is configured with 192.168.3.254/22, then site 2's config should have 192.168.0.0/22 in the IPv4 Remote network(s) section.
I haven't seen anything overly complicated here. What you're trying to accomplish is fairly straight forward. We need to get the traffic routed over the tunnel and then allowed through the firewall at both ends.
I'd suggest a few things until you establish basic IP communication:
-
Post your server1.conf and client1.conf (both located here -> /var/etc/openvpn)
-
Turn off the software firewall on the endpoints you're testing with.
-
On site 1, verify there's a LAN net/any rule on the LAN tab
-
On site 1, add an any/any rule to the VLAN60 tab
-
On site 2, in the OpenVPN client config, modify the IPv4 Remote network(s) section so it reads "192.168.0.0/22, 192.168.60.0/24"
-
On site 2, verify there's a LAN net/any rule on the LAN tab
-
Add an any/any rule on the OpenVPN tab on both ends
-
Verify all devices are using PFsense as the default gateway and have the correct subnet mask configured.
-
On site 1, verify VLAN60 is configured with the network and mask you're expecting it to have. If you find a discrepancy, modify the IPv4 Remote network(s) section on site 2's config.
-
-
@viragomann thank you for the reply, so i changed on the part which i made a mistake to 192.168.0.0/22
so from pfsense 2 i ping pfsense 1 LAN which is 192.168.3.254 which worksPING 192.168.3.254 (192.168.3.254): 56 data bytes 64 bytes from 192.168.3.254: icmp_seq=0 ttl=64 time=42.462 ms 64 bytes from 192.168.3.254: icmp_seq=1 ttl=64 time=40.182 ms 64 bytes from 192.168.3.254: icmp_seq=2 ttl=64 time=40.086 ms --- 192.168.3.254 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 40.086/40.910/42.462/1.098 msbut not to IP 192.168.60.100
The part of change the source address to LAN? not sure what you mean on firewall rules on pfSense 1?
-
@marvosa Thanks for the reply, correct i fixed that part which i configured wrong but still cannot ping 192.168.60.100
this is my Server config of pfsense site 1
dev ovpns2 verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 181.143.xx.xx ifconfig 192.168.90.1 192.168.90.2 lport 1195 management /var/etc/openvpn/server2.sock unix max-clients 10 route 192.168.15.0 255.255.255.0 secret /var/etc/openvpn/server2.secret compresspfsense site 2
dev ovpnc1 verb 1 dev-type tun 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 udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 181.57.xx.xxx lport 0 management /var/etc/openvpn/client1.sock unix remote 181.143.xx.xx 1195 ifconfig 192.168.90.2 192.168.90.1 route 192.168.0.0 255.255.252.0 route 192.168.60.0 255.255.255.0 secret /var/etc/openvpn/client1.secret compress resolv-retry infinitesite 2 pics
site 1 pics
-
Configs look good, so once packets from site 2 hit the firewall that are destined for 192.168.60.0/24, they should get routed to site 1. Conversely, once packets from site 1 hit the firewall that are destined for 192.168.15.0/24, they should get routed to site 2.
At this point, it's all going to be troubleshooting, I would run a traceroute on both ends, see where the packets stop and troubleshoot from that point. Something is interrupting (or blocking) packet delivery, so every point along the data path will need to be traced and examined. Start checking routing tables, conflicting static routes, firewall logs, and re-examining firewall rules. I would also verify that there are no persistent routes on the endpoints you're testing with.
A couple of things I see that should be looked at:
- On the LAN tab on site 2, that LAN net/192.168.60.0/24 is redundant (since there's a LAN net/any right below it), but since the rule is there... it does appear to give some insight. There do not appear to be any hits on that LAN net/192.168.60.0/24 rule, which suggests that traffic may not be making it to the firewall, so that will need to be looked at.
- I'm not sure what the TELEFONIAIP tab is (maybe VLAN 60?) but if it's something that you're trying to hit from site 2, there also appear to be no hits on the any/any rule, so it looks like traffic isn't making it there.
We also have no insight into the network design at each end, so if there are any downstream routers, L3 switches, dual WAN, isolated networks behind a 2nd firewall, etc... that will all have to be looked at.
-
@marvosa Thank you for the reply, so troubleshooting this still cannot ping the VLAN 60.
On the LAN tab on site 2, that LAN net/192.168.60.0/24 is redundant (since there's a LAN net/any right below it), but since the rule is there... it does appear to give some insight. There do not appear to be any hits on that LAN net/192.168.60.0/24 rule, which suggests that traffic may not be making it to the firewall, so that will need to be looked at.i added the rule thinking it was needed but i guess its not needed
I'm not sure what the TELEFONIAIP tab is (maybe VLAN 60?) but if it's something that you're trying to hit from site 2, there also appear to be no hits on the any/any rule, so it looks like traffic isn't making it there.correct that is the VLAN60 but howcome no traffic even if i put on the VPN to be able to see it?
as for the traceroute
i ran from a server which has 192.168.15.253 on site and got this on the states of site 2 pfsenseLAN udp 192.168.15.216:40450 -> 192.168.60.100:33469 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:40450 -> 192.168.60.100:33469 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:49537 -> 192.168.60.100:33470 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:49537 -> 192.168.60.100:33470 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:60136 -> 192.168.60.100:33471 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:60136 -> 192.168.60.100:33471 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:39725 -> 192.168.60.100:33472 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:39725 -> 192.168.60.100:33472 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:37392 -> 192.168.60.100:33473 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:37392 -> 192.168.60.100:33473 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:37383 -> 192.168.60.100:33474 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:37383 -> 192.168.60.100:33474 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:47801 -> 192.168.60.100:33475 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:47801 -> 192.168.60.100:33475 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:43818 -> 192.168.60.100:33476 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:43818 -> 192.168.60.100:33476 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:41138 -> 192.168.60.100:33477 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:41138 -> 192.168.60.100:33477 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:45075 -> 192.168.60.100:33478 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:45075 -> 192.168.60.100:33478 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:43683 -> 192.168.60.100:33479 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:43683 -> 192.168.60.100:33479 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:58588 -> 192.168.60.100:33480 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:58588 -> 192.168.60.100:33480 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:39537 -> 192.168.60.100:33481 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:39537 -> 192.168.60.100:33481 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:37876 -> 192.168.60.100:33482 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:37876 -> 192.168.60.100:33482 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 B LAN udp 192.168.15.216:45678 -> 192.168.60.100:33483 NO_TRAFFIC:SINGLE 1 / 0 60 B / 0 B ovpns2 udp 192.168.15.216:45678 -> 192.168.60.100:33483 SINGLE:NO_TRAFFIC 1 / 0 60 B / 0 Band this is the traceroute
traceroute 192.168.60.100 traceroute to 192.168.60.100 (192.168.60.100), 30 hops max, 60 byte packets 1 192.168.15.254 (192.168.15.254) 0.405 ms 0.397 ms 0.385 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *on the states on pf Sense site1 i never see any traffic on must i be missing something?
Thank you
-
As you can see from the traceroute, the traffic never makes it to the tunnel. The question is why. If there's no added complexity behind PFsense on either end, the first thing I would do is start checking routing tables on both endpoints and both PFsense boxes.
If you post the routing tables we may be able to help. Also, are either of your endpoints dual-homed?
-
Thanks for the reply, thats correct thats what bugging me the rules are simple on both firewalls
This is my routing tables pfsense site 1
default 181.143.xx.xx UGS 1010912193 1500 vtnet1 8.8.8.8 181.143.xx.xx UGHS 6852794 1500 vtnet1 10.0.3.192/26 link#13 U 12109832 1500 vtnet0.20 10.0.3.194 link#13 UHS 0 16384 lo0 10.10.10.1 link#1 UHS 27686 16384 lo0 10.10.10.1/32 link#1 U 0 1500 vtnet0 127.0.0.1 link#5 UH 173093818 16384 lo0 181.57.194.xx/30 link#3 U 20474263 1500 vtnet2 181.57.194.xx link#3 UHS 3 16384 lo0 181.143.xx.xx/29 link#2 U 0 1500 vtnet1 181.143.xx.xx link#2 UHS 0 16384 lo0 181.143.xx.xx/32 link#2 U 0 1500 vtnet1 181.143.xx.xx link#2 UHS 305 16384 lo0 181.143.xx.xx/32 link#2 U 0 1500 vtnet1 181.143.xx.xx link#2 UHS 194 16384 lo0 181.143.xx.xx/32 link#2 U 0 1500 vtnet1 181.143.xx.xx link#2 UHS 0 16384 lo0 181.143.xx.xx/32 link#2 U 0 1500 vtnet1 181.143.xx.xx link#2 UHS 0 16384 lo0 192.168.0.0/22 link#1 U 1163422258 1500 vtnet0 192.168.3.254 link#1 UHS 1496054 16384 lo0 192.168.5.0/24 link#17 U 4110530 1500 vtnet0.5 192.168.5.2 link#17 UHS 0 16384 lo0 192.168.7.32/27 link#8 U 279119732 1500 vtnet0.10 192.168.7.62 link#8 UHS 0 16384 lo0 192.168.7.64/28 link#22 U 0 1500 vtnet0.7 192.168.7.70 link#22 UHS 0 16384 lo0 192.168.12.0/24 link#10 U 21201511 1500 vtnet0.12 192.168.12.254 link#10 UHS 0 16384 lo0 192.168.15.0/24 192.168.90.2 UGS 324 1500 ovpns2 192.168.50.0/24 link#18 U 745106863 1500 vtnet0.50 192.168.50.2 link#18 UHS 0 16384 lo0 192.168.51.0/24 link#20 U 39831878 1500 vtnet0.51 192.168.51.2 link#20 UHS 0 16384 lo0 192.168.52.0/24 link#19 U 395334421 1500 vtnet0.52 192.168.52.2 link#19 UHS 0 16384 lo0 192.168.60.0/24 link#21 U 3543023 1500 vtnet0.60 192.168.60.254 link#21 UHS 1 16384 lo0 192.168.90.1 link#25 UHS 0 16384 lo0 192.168.90.2 link#25 UH 3 1500 ovpns2 192.168.100.0/24 192.168.100.2 UGS 85978764 1500 ovpns1 192.168.100.1 link#24 UHS 0 16384 lo0 192.168.100.2 link#24 UH 3629147 1500 ovpns1 208.69.xx.xx 181.57.194.xx UGHS 6852765 1500 vtnet2site 2 pfsense
127.0.0.1 link#4 UH 474 16384 lo0 181.57.181.xx/30 link#2 U 647756 1500 vtnet1 181.57.181.xx link#2 UHS 0 16384 lo0 192.168.0.0/22 192.168.90.1 UGS 7989 1500 ovpnc1 192.168.15.0/24 link#1 U 46543 1500 vtnet0 192.168.15.254 link#1 UHS 0 16384 lo0 192.168.60.0/24 192.168.60.2 UGS 64 1500 ovpns2 192.168.60.1 link#8 UHS 0 16384 lo0 192.168.60.2 link#8 UH 18790 1500 ovpns2 192.168.90.1 link#7 UH 0 1500 ovpnc1 192.168.90.2 link#7 UHS 0 16384 lo0 -
- Site 1 shows 192.168.15.0/24 being routed towards 192.168.90.2 through the ovpns2 interface, which is site 2's end of the tunnel and is expected
- Site 2 shows 192.168.0.0/22 being routed towards 192.168.90.1 through the ovpnc1 interface, which is site 1's end of the tunnel and is expected
- However, Site 2 also shows 192.168.60.0/24 being routed towards 192.168.60.2 through the ovpns2 interface. <---Here's your issue... and it's the reason why traffic is never leaving site 2. Based on the site 2 config you posted, we should be seeing 192.168.60.0/24 being routed towards 192.168.90.1 on the ovpnc1 interface.
So, you have a conflict @ site 2 that is screwing up your routing. Per site 2's routing table, 192.168.60.0/24 is already being routed somewhere else in another server instance (ovpns2), which should correspond to server2.conf. You will have to find the server instance that's running at site 2 with the duplicate entry of 192.168.60.0/24 somewhere in the config and make adjustments accordingly.
-
Thanks for the reply, so the issue is on the site 2 pfsense?
so from what i understand that site 2 is routing the the network 192.168.60.0/24 in another server?
I checked on the site 2 pfSense box any rules that has that network but nothing. wouldn't that route be what i put on the site to site option to route?
My other question is why does it show ovpns2?Thank you
-
o wait forget it
your right i forgot the pfsense 2 has VPN server with 60 o god i feel dump
sorry
thank you again
