I think Pfsense is blocking ping.
-
Do you have a static route on Router pointing to pfSense for 10.10.10.0/24, it would try and push the traffic down the default gateway otherwise ?
If you do a packet capture on the pfSense WAN interface do you even see ping ( ICMP ) packets hitting the interface ?
Diagnostics -> Packet Capture
Also check the WAN interface and untick:-
Block private networks and loopback addresses
You'll also have NAT issues, there are 3 RFC1918 subnets, 172.20.18.X, 192.168.1.X & 10.10.10.X
-
@utilizador_estagio said in I think Pfsense is blocking ping.:
being on the 172.20.18.0/24 network (my job)
Where is your job? And what IP are you trying to ping? A IP 2 routers deep? That is a rfc1918 address.. Are you just trying to hide your public IP?
As asked already are you natting? At pfsense and that router? And then again before that 172.20 address? Or are you all local to this.. And that router in front of pfsense is not natting?
-
In the router I already have a static route pointing to 10.10.10.0/24. I've also disabled the two blocking options in the WAN rule. I have already done the diagnostic test to see if the ping is coming to the WAN interface. Even so, it still does not work.
When I set up the network I was not having access to the internet, I had to do nat on the router and I got to the internet. My work network is 172.20.18.0/24.
rotas:
-
The internet hits my work by public ip provided by an internet provider and then a private network is created 172.20.18.0/24. I have to do nat also in pfsense? From network 10.10.10.0/24 I can ping the network from my work but the reverse does not.
-
I'm guessing there are no ACLs on FastEthernet0/1 ?
Post your pfSense firewall rules & static routes.
Pings from 192.168.1.2 -> 192.168.1.1 should work as they are directly attached.
-
So the internet is between you at work and this router and pfsense.. Or is this router and pfsense at your work location?
you can not route rfc1918 addresses over the internet.. You would need a vpn to connect your work rfc1918 network to some other location also using rfc1918 behind a nat router connected to the internet.
Your drawing doesn't make a lot of sense if its local. But if its all local then you just need to turn off all nat on that router and pfsense and route your traffic and allow it in the in the firewall in pfsense.
Where exactly did you do that sniff? That just looks like pfsense monitoring its gatways??
-
Yes. Ping 192.168.1.2 -> 192.168.1.1 Works
But ping 192.168.1.1 -> 192.168.1.2 does not work -
@utilizador_estagio said in I think Pfsense is blocking ping.:
But ping 192.168.1.1 -> 192.168.1.2 does not work
Out of the box pfsense wan blocks all unsolicited traffic.. If you want to ping pfsense wan IP, you would have to allow that in the wan rules on pfsense.
If all of this is local to your work, not understanding the point of the "router" in your diagram, why do you not just connect pfsense directly this 172.20.18 network?
-
Okay. I'll reframe everything and I'll come back with the whole scheme and explain what's going on. Thank you.
-
Ok, i am back. Here is the issue.
I'm using the test router because the purpose is to test the features of pfsense, such as the locks that one can do and these things, and my boss told me to use a test router to create a subnet so as not to interfere with the network of work (172.20.18.0/24). The network created was 192.168.1.0/24 and I configured static addressing on the router and assigned the addresses shown in the figure.
At first I did not have internet because I needed to do the nat on the test router. I did it and it worked because I was able to access the internet on the test router. then I switched on pfsense and configured it with the addresses shown in the figure. Now my PC is connected to the network 10.10.10.0/24. (DHCP). I still have internet access. I created a samba server on the ubunto to share file. It works. inside the 10.10.10.0/24 network all right. The problem appears when I try to access the server through the network (172.20.18.0/24). I can not. If I am inside the 10.10.10.0/24 network I can ping out of pfsense, for example to a machine on the network. 172.20.18.0/24. But if I am inside the network 172.20.18.0/24 I can not ping the network 10.10.10.0/24, not even in the WAN address of pfsense.
I've already disabled blocking options on 'reserved networks' in pfsense's WAN interface. I have also created a rule to allow pfsense to ping. I have already made the diagnosis to know if the ping is coming to the WAN interface of pfsense.
What to do ? -
Note: I am an intern starting at pfsense.
-
Allowing ping, i did:
Action: allow
Interface: WAN
Address Family: IPv4
Protocol: ICMP
ICMP subtypes: any
source. any
destination: WAN net -
So where exactly is your source and what IP are you pinging exactly.
If your on this 172.20.18 network, with a default gateway of 172.20.18.1 and your pinging 10.10.10.20?
Or are you on the public internet? You have a triple nat looks like? Which router(s)/pfsense are natting which are not?
In such a setup both 172.20.18 and 192.168.1 are transit networks and there should be no "hosts" on them - if there are and you want to get to downstream networks you would need to do routing on the hosts themselves.
-
i am pinging from 172.20.18.190 to 10.10.10.20
172.20.18 default gatway is 172.20.18.1 -
Yeah that is going to be asymmetrical mess then... If your going to connect downstream routers, then the network that connects them is transit and no host should be on it. If you put hosts on a transit network then you have to route on the host or your traffic is going to be asymmetrical.
Also are either of these downstream routers from your edge natting or not?
From your drawing router 2 and pfsense are downstream from your edge router 1
-
I would eliminate router 2 from the set up and put the 192.168.1.0/24 network on an OPT interface on pfSense (assuming the network is needed at all). You have an awful lot of routers chained and managing routing and NAT (outbound NAT on the edge router) between all of those local networks is going to be a pain. Simplify your setup.
