How to check/enable antispoofing
-
@johnpoz said in How to check/enable antispoofing:
Doesn't Work that way....
i would same the same.
"With your tcpdumps you were doing - do them with the -e flag" - would've been my next step.
-
Ok, so here is the drawing. If it is not clear enough, let me know.
Here are two captures made simultaneously on the FW2 which is the Pfsense and on the NAS physical server. The test consists in: open a http session from PC 10.40.40.4 vlan 40 towards the NAS mgmt interface vlan 100 10.100.100.6.
FW2_MERGE.pcap
NAS_MERGE.pcap
The captures were made on:
-NAS both mgmt and prod interface
-Pfsense interface prod vlan 35 and interface vlan 100IPs:
10.100.100.6 -> NAS vlan 100 mgmt
10.40.40.4 -> PC vlan 40MACs:
00:0c:29:c3:ed:8c - > PFsense interface (it has only one interface with multiple subinterfaces/vlans)
c8:cb:b8:c5:26:7d - > NAS interface mgmt vlan 100
00:1b:21:81:91:10 - > NAS interface prod vlan 25
40:8d:5c:55:70:50 - > PC interface vlan 40Let me know dude, if i should add more details.
-
@panicos said in How to check/enable antispoofing:
FW2 which is the Pfsense and on the NAS physical server.
Ok confused... If FW2 is on the NAS.. Then how do you have your lagg setup there with both trunk all and access 35? They are the same physical port? Are they not if those are the interfaces connected to your host..
Where is your vlan and interface setup for for this FW2, and what is FW1? How does vlan 40 even talk to vlan 100, from that drawing you can not tell that fw1 or fw2 even has an interface in vlan 100.. And is it tagged or untagged into pfsense?
So these 4 physical ports you have set as access 35, and Trunk? Yeah you can not put a port in access and trunk mode at the same time.. traffic is either tagged or not tagged.. So the native untagged is 35? What is the pvid on these ports - assume 35.. So any untagged traffic coming off the server gets put in 35 vlan?
So that drawing isn't making a lot of sense.
-
ok, then. in this case, thank you .
-
Coming back to my first question, can anyone say how can i enable or disable antispoofing (reverse path check) on pfsense?
-
@panicos said in How to check/enable antispoofing:
disable antispoofing (reverse path check) on pfsense?
There is no such thing. Do you mean allowing for asymmetrical traffic where pfsense sees syn,ack when there was not syn to create the state..
How about you do this..Remove all your lagg setup, and do just physical paths and with actual isolation... Do you see the problem then?
A server would never send traffic out a different interface with different source IP.. What OS do you think works that way?? How would you think it would even know to do that?
Sure you can do it with generating packets and such, but no normal OS routing or stack would do such a thing..
What are those mac address.. your sending to a HP mac c8:cb:b8, from vm mac... But your return is to intel 00:1b:21
-
I believe the OP is talking about behaviors that a few firewalls have, Checkpoints in particular. Here is a link to a short description of the feature -- http://www.jay-miah.co.uk/configuring-anti-spoofing-on-a-checkpoint-firewall/.
So far as I know, @johnpoz is correct that no such feature exists in pfSense. At least I know of no such directly configurable similar feature.
I managed Checkpoint firewalls for several years and anti-spoofing was one of those really cool but really irritating features. It usually raised its head and blocked stuff somewhat invisibly when you were creating complex configurations such as VRRP.
-
man, please, understand what i am saying and stop saying the otherwise.
What OS do you think works that way?? --> for instance, FreeBSD works that way.
The reverse patch check is a kernel setting. In some Linux distributions (like Ubuntu for instance) it is enabled by default. I don't know how is it in FreeBSD, but judging by its behaviour, it is not enabled.
If you want to help me, please post relevant messages to what i am asking and stop seeing problems where there actually aren't. -
Give us the Mac address - see my edits... You have what looks like asymmetrical flow.. You send to mac A, but get answer back from mac B.. one is HP, the other is intel..
So that traffic is not flowing back through pfsense..
Reverse path filtering is router thing - what OS that is NOT being used as a router would do such a thing? None of them.
Good luck - you have a complete and utter mess with such a setup.. So no shit your going to see all kinds of problems...
-
@bmeeks said in How to check/enable antispoofing:
or several years and anti-spoofing w
Hi, yes, Checkpoint is an example.
I am here refering to Reverse Path Filter. It is called like that on Linux, but i don t know how is it on FreeBSD.
In my case, the Pfsense (which is a freebsd as far as i know) receives a packet on an interface that it should not be receiving it and it allows it; i want to know if i can enable the feature that blocks it.
Further explination: the firewall has interface A and interface B. The firewall receives a packet with source IP from interface B , but it receives it on interface A instead of receiving it on interface B and it allows it. I want to know how i can block this. -
As i said. Please stop. You are not reading my posts and my captures and all i added. Stop adding confusion.
-
@panicos said in How to check/enable antispoofing:
@bmeeks said in How to check/enable antispoofing:
or several years and anti-spoofing w
Hi, yes, Checkpoint is an example.
I am here refering to Reverse Path Filter. It is called like that on Linux, but i don t know how is it on FreeBSD.
In my case, the Pfsense (which is a freebsd as far as i know) receives a packet on an interface that it should not be receiving it and it allows it; i want to know if i can enable the feature that blocks it.
Further explination: the firewall has interface A and interface B. The firewall receives a packet with source IP from interface B , but it receives it on interface A instead of receiving it on interface B and it allows it. I want to know how i can block this.I don't believe FreeBSD has that capability, or at least it is not compiled into the kernel's firewall engine by default. pfSense is really just a few patches on top of FreeBSD, so if FreeBSD does not have something then generally pfSense will not have it either.
Here is a very old thread from the Netgate forums discussing the feature: https://forum.netgate.com/topic/2228/rp_filter/3. I also found a handful of Google links suggesting you can sort of mimic anti-spoofing using some features of the
ipfwfirewall on FreeBSD. However, in pfSense, theipfwfirewall engine has been modified a little and is used solely for Captive Portal operation. The firewall engine used in pfSense for controlling network traffic ispf. -
@bmeeks said in How to check/enable antispoofing:
I don't believe FreeBSD has that capability, or at least it is not compiled into the kernel's firewall engine by default. pfSense is really just a few patches on top of FreeBSD, so if FreeBSD does not have something then generally pfSense will not have it either.
Here is a very old thread from the Netgate forums discussing the feature: https://forum.netgate.com/topic/2228/rp_filter/3. I also found a handful of Google links suggesting you can sort of mimic anti-spoofing using some features of the ipfw firewall on FreeBSD. However, in pfSense, the ipfw firewall engine has been modified a little and is used solely for Captive Portal operation. The firewall engine used in pfSense for controlling network traffic is pf.Yes bmeeks, i also saw that thread before, but it is indeed very old; i had the impression that maybe something changed in the last 14 years, since then.
So i guess, that means the antispoof i want to enable is just not possible, right? -
@panicos said in How to check/enable antispoofing:
@bmeeks said in How to check/enable antispoofing:
Yes bmeeks, i also saw that thread before, but it is indeed very old; i had the impression that maybe something changed in the last 14 years, since then.
So i guess, that means the antispoof i want to enable is just not possible, right?Correct. I don't think the feature has made it into the
pfengine used for controlling traffic on pfSense.You might consider opening a Feature Request on the pfSense Redmine site here: https://redmine.pfsense.org/. In my search I did see a number of discussions about a recent (as in 2019) VPN vulnerabililty that is exploited using spoofing techniques that "anti-spoofing" is designed to prevent.
-
ok, thanks. i will need then to find different alternatives to this situation.
Thx a lot. -
Well if properly filtered at L3 wouldn't be an issue what your NAS does for return traffic.. Because your box would never be able to hit the 100 vlan address in the first place.
-
@bmeeks said in How to check/enable antispoofing:
believe the OP is talking about behaviors that a few firewalls have, Checkpoints in particular.
Fortigate too.
-
But that only comes into play with routers.. Why would you "server" being do it.
Routers that have multiple path it makes sense so... But not when OS is being used as on a local network..
-
This post is deleted! -
Referring all the way back to the OP's very first post and simplified diagram, this is what I understand is going on.
You initiated a ping from host 10.40.40.3 to host 10.100.100.7. The pfSense firewall has both networks (the 10.40.40.0 and the 10.100.100.0) locally attached along with 172.35.35.0. Just assuming for this example all the networks are a /24 subnet.
So your ping towards 10.100.100.7 was routed by the firewall directly to the host on 10.100.100.7 via the local attachment. That target host (10.100.100.7) is actually a dual-homed server with two different interfaces. It's internal routing is set up such that 172.35.35.x is the default route (or the gateway). So when that dual-homed server is ready to return the reply to 10.40.40.3 it sees that is not on its network so it hands it off to the gateway at 172.35.35.x to route. The gateway sees that 10.40.40.3 is locally attached so it just routes the packet straight over to VLAN 40 and back to the originating host.
Now the above assumes the firewall has no rules (or they are all "any any pass"). In a typical firewall scenario with rules, the reply coming in to VLAN 35 (from the server host's default route) would be dropped due to being out of state. You did not share your firewall rules.
I don't really see where anti-spoofing comes into play in this scenario.
Or am I just dazed and dense and not seeing something obvious ???
