IPSEC traffic denied by default IPv4 Rule
-
Sounds like packets to the printer are not flowing along the same path as from the printer.
If you're thinking sloppy states will fix it, it sounds like you are already suspecting asymmetry in your routing somewhere.
Best thing to do is design the network so packets flow in an out "properly."
-
I was on that track, but everything else from the network is working properly. It is only the MFP devices, I also do not have this issue with other MFPs at other remotes terminating to this pfsense box. I can send NTP fine from the device, but when I try to browse http from the datacenter network to the device the packets are blocked inbound.
From other devices:
It is also experienced from a Canon and a Ricoh printer.
-
Are their default gateways set the same as the rest?
-
Yes, default gateway set the same on all of the devices.
-
Is that default gateway the pfSense device or some other router on your network?
You are almost certainly seeing asymmetry. You just need to identify it and fix it.
-
Default gateway on that network goes direct to the router which is the VPN device terminating to the pfsense on the other side. On the pfsense there is a route pointing to distribution switch in the datacenter.
It just seems that if I had a routing issue it would affect all devices on the network there.
-
Sorry. Going to need some sort of diagram. Right. And if it was all correct it would be working for all devices, not just some. When it's asymmetric some devices deal with things like ICMP redirects differently.
-
-
OK there's nothing special there.
In the firewall log it looks like there is a connection from 10.77.84.24 to 10.77.87.3 that is failing for some reason.
That looks like the initial connection is blocked inbound but it is not a SYN. Then the next packet is from the same source/dest but is an ACK. That doesn't make much sense. And it looks like they are both arriving over the tunnel that way. The firewall is (apparently correctly) rejecting the connection.
I would be looking at the differences between the TCP connections that work in that direction and those that don't. And from what I can tell the problem is on the other side.
You might need to pcap and examine that traffic to see what's actually going on.
What are the rules on your IPsec tab?
Is there a GRE or anything in the mix here or just a straight IPsec transport VPN?
-
Straight IPSEC, rule on IPSEC right now to allow all protocols ipv4/ipv6 any any. I can open a TAC case with Cisco and see what we come up with, will post the results in case anyone else runs across this issue.
-
I have been informed that another possibility is those logs are the result of fragmented traffic that, for some reason, cannot be reassembled.
A packet capture might reveal something there as might looking at the raw firewall logs. You can see them by checking the Show raw filter logs checkbox in System > Logs, Settings or by doing something like
clog /var/log/filter.log | grep '10\.77\.84'. -
Yes, Cisco just asked for that. We are going to do a packet capture on both ends.
