Cant ping my netgate remotely or webgui into firewall.
-
Those devices are all in the same subnet. So assuming they all have the same subnet mask, /23, they should be talking directly.
I suspect if you ran a packet capture on the pfSense LAN whilst trying to ping it from 10.210.22.24 you would see it ARPing for that address and not seeing any replies.
Unless the client is also unable to ARP for the pfSense IP in which case you would see nothing.Can you ping 10.210.22.24 from pfSense?
The VPN should carry ARP if it's really layer 2 but something might be filtering that.
We would need to see a packet capture to diagnose further.
Steve
-
@johnpoz Sorry let me correct myself.... We have connections via T1 at some sites, routed through BGP hitting our MPLS and back to our corp office. We also have some sites using broadband connections that we use EZVPN, setting our router as a client with a username and password for authorization.
Yes i do understand that the current rules (any any) arn't doing anything. I only set that to try and at least be able to ping the firewall remotely. I do plan on setting rules once i can figure out how to remotely manage the firewall.
We have over 300 remote sites all of the private subnets we use for them are extended back to our corp office and can connect to them via those private IPs.
-
This post is deleted! -
-
Sorry, I misread your post earlier. I assume 10.210.22.24 is in fact pfSense?
And 10.210.22.1 is the Cisco router?
Where was this capture taken, on the pfSense LAN?
I assume you have the configured as a gateway in pfSense which is why it's pinging it at 0.5s intervals.
What is your test client that's failing here, .209?
20:48:09.945303 IP 10.210.22.209.49486 > 10.210.22.24.443: tcp 1 20:48:09.945339 IP 10.210.22.24.443 > 10.210.22.209.49486: tcp 0There are no failing ARP requests shown at least. pfSense is seeing that test traffic (assuming .209) and replying via the correct interface. The actual pcap file would show if it's using the correct MAC there.
Steve
-
@stephenw10
.24 is the PFSense, 10.210.22.1 is the cisco router. the .209 is the PC that i had plugged into another lan port on the PFSense so i could go into the web gui to run the packet capture. I pinged remotely from my office PC at 10.160.34.69. -
Ok so there are no replies leaving the LAN (assuming it was captured on the LAN).
Does pfSense have a route to 10.160.34.X? Via 10.210.22.1?
It's probably sending replies via it's default route otherwise.
Steve
-
There isn't a route on the PFSense to 10.160.34.x , but on my cisco router 10.210.22.1 goes out VPN to our office network which has a route to this network.
Not sure if it helps but i ran a ping to the .209 which is the PC connected to LAN port on PFSense, and i do get replys from my 10.160.34.69 PC Remotly.
0_1539107007783_packetcapture2.txtHere is also a pic of the routes i currently have on pfsense. 10.1.10.1 is the interface on my comcast modem.
-
Hmm, that's interesting.
You can ping the client at .209 because it's getting it's IP from the router at .1 so will be using that as it's default gateway and has a route back to 10.160 via that.Normally I would expect pfSense not to unless you added a static route (we can see only the gateways not the static routes) but here you have set the LAN side gateway as default.
I would check the routing table in pfSense, Diag > Routes, to be sure.
Steve
-
-
Ok, should be good.
The default LAN pass rule will not pass that of course as LANnet does not include it.
You would see that traffic blocked in the firewall log though unless you have default block logging disabled.Otherwise run a pcap on WAN to be sure replies are not going that way for some reason.
Steve
-
Success!! God idk why i didn't find that earlier.... After checking the firewall log it was blocking ICMP packets to 10.210.22.24 from my remote network. Made an easy rule to allow it and now i can ping and get to the webgui remotely.
Thanks alot for helping me find the answer!!
-
but now i cant get out to public internet lol... Probably firewall rule i need to allow. Calling it a day and will continue tomorrow. Thanks again
-
Yes, the easyrule won't cover that.
Easy to overlook LANnet as source in the rules
Steve
