How to check/enable antispoofing
-
Hello,
I have a virtual pfsense and i guess antispoofing is not working on it. It should, but i don t think it is working, because i have the following scenario:
- host A "just a machine" connected to pfsense on vlan 40
- host B "server" connected to pfsense with two interfaces: one interface vlan 35, another interface on vlan 100. Host B has default route on vlan 35 and no gateway/no route on vlan 100.
When i connect (ssh, http, whatever) from host A to host B (using vlan 100 interface of host B), it works. This is asymmetric traffic: returning traffic expected on interface vlan 100 of the firewall goes actually through interface vlan 35.
Image bellow explains the behaviour.
Why isn't the firewall blocking this traffic? Is the antispoofing off? I tried to follow the manual in an attempt of finding the configurations for antispoofing, but it is not clear where these can be found.
I have no floating rules.
Final question: how can i enable antispoofing on pfsense?
Thx
-
Yeah I don't think its working how you think its working.. You sure your not source natting the traffic there on your vlan 100 interface of your pfsense.
Lets see the sniffs on this server of your traffic entering on vlan 100 interface, and then answer going out vlan 35 interface..
Forget the asymmetrical... Your clients wouldn't accept the answer.. I wanted to talk to 10.100.100.7, sure not going to think that answer from 172.35.35.6 is valid..
Your client itself would say F off!!!
also want to see the sniff on this machine showing a syn going out to 100.x and getting syn,ack from 172.35 and thinking that is ok..
-
Hello Johnpoz,
"Forget the asymmetrical... Your clients wouldn't accept the answer.. I wanted to talk to 10.100.100.7, sure not going to think that answer from 172.35.35.6 is valid.."
The address does not change from 10.100.100.7 to 172.35.35.6; it just gets routed through 172.35.35.6 interface, but it does not hide behind its IP.
Please see files attached with tcpdumps and wireshark capture on the source host.
The IPs in the captures are the real ones (they are a bit different from the drawing, but it is the same situation anyway).
Let me know if i should add other details as well.Thx
-
@panicos said in How to check/enable antispoofing:
it just gets routed through 172.35.35.6 interface, but it does not hide behind its IP.
Doesn't work that way - not possible!
Dude your on VM interfaces and and a lagg (what are the members of the lag?) And what is your configuration of the vswitches your connecting too.. You doing VST, VGT or EST? You clearly have some tags going on there, but how are you doing the tags in the vswitches, and how do you have them connected via physical into this VM host that is running pfsense.
-
@johnpoz said in How to check/enable antispoofing:
oo.. You doing VST, VGT
Well, dude, i don't really have a lot of knowledge with ESX, but i guess i am doing VST and EST. It goes like this:
Pfsense is virtual, hosted on a server which is using vswitch (not vDswitch). This host is physically connected to a cisco switch with a trunk allowing all vlans (at both ends of the link). Further on, the physical server with the lagg is connected to the cisco switch as follows:
-one physical interface (vlan 100)
-4 physicall interfaces in LACP (vlan 35). So a portchannel made up of 4 physical interfaces.Is there a problem with the setup?
"Doesn't work that way - not possible!" -> possible or not, it is what i see in the dumps, if i am not missing something. Have you seen the dumps?
-
Your missing the tags being added or not added, and you have a lagg interface, so what physical interface is running.
What do you have set for your vswitches in esxi?
This host is physically connected to a cisco switch with a trunk allowing all vlans (at both ends of the link).
So this esxi box has 1 physical interface? Connected your vswitch, what is the vlan id set on the port group in the vswitch that your physical nic is connected too. If your doing VST, then your handling the tags... in the vswitch and they would be removed before sent to the VM... So why would you have pfsense interfaces set as vlans and not different vnics..
So yeah you got something major messed up.. If your thinking traffic is routing out different physical interface of physical server with IP address X on it with IP Y as the source traffic - that is NOT going to happen..
What you having going in is lack of tags and amounts to running multiple layer 3 networks on the same layer 2.. What your describing if the vlans were correctly isolated just can not happen.. So clearly you have something wrong with your vlan isolation.
-
"Your missing the tags being added or not added, and you have a lagg interface, so what physical interface is running."
Not so sure about missing tags. I rally cannot find an issue with the layer 2, but maybe i miss something.
Lagg interface is a bundle of 4 interfaces. as i previously stated:
-one physical interface (vlan 100) -> this has nothing to do with the lagg below.
-4 physicall interfaces in LACP (vlan 35). So a portchannel made up of 4 physical interfaces. -> this has nothing to do with the interface vlan 100 above."What do you have set for your vswitches in esxi?" - one vswitch holding only the mgmt interface, no tagging there. Another vswitch holding a trunk all interface towards the firewall.
"So this esxi box has 1 physical interface?" - no, it has 6 physical interfaces, 2 of them independent, the rest of 4 bundled in a port channel.
"If your doing VST, then your handling the tags..."- the switch has trunk all interfaces regarding the firewall traffic. The firewall is handling the tagging. I can't see a problem here.
The switch is doing VST only for some portgroups leading to some virtual machines."Connected your vswitch, what is the vlan id set on the port group in the vswitch that your physical nic is connected too." - it is a trunk all
"So yeah you got something major messed up.." - are you sure?
"What you having going in is lack of tags and amounts to running multiple layer 3 networks on the same layer 2." - harsh diagnostic i would say; very apocalyptic.
I tried replicate the problem with other hosts as well, both physical and virtual and the situation is not the same. So it appears that only the server box is behaving like this.
-
@panicos said in How to check/enable antispoofing:
"So yeah you got something major messed up.." - are you sure?
YEAH.. If your doing VST... Then you wouldn't have vlans on pfsense interfaces in the first place.. They would be just native vnics.. Only when you set your vswitches with VGT would pfsense ever see tags... And need vlan setup. If you want pfsense to see the tags then you would have to set vlan ID 4095 on the port group the vnics of pfsense are connected too, or esxi will be stripping tags..
Post up your networking config of your esxi...
Actually draw the actual physical connections and how you have your switch configured..
-
@johnpoz said in How to check/enable antispoofing:
If you want pfsense to see the tags then you would have to set vlan ID 4095 on the port group the vnics of pfsense are connected too, or esxi will be stripping tags..
It is configured like that.
"Post up your networking config of your esxi...
Actually draw the actual physical connections and how you have your switch configured.." - i will return later with these details.
-
@panicos said in How to check/enable antispoofing:
It is configured like that.
Then your not doing VST..
This is VGT
https://kb.vmware.com/s/article/1004252
-
@johnpoz said in How to check/enable antispoofing:
Then your not doing VST..
not on the link towards the firewall, no.
I am doing VST on other portgroups of the same vswitch, but leading to other virtual machines (which in this moment are not existing). so the only portgroups where i am doing VST, are not assigned to any VM in this moment.
-
You need to lay this out... Because there is no possible why it works how you say its working... For starters a server doesn't say oh I got this connection from X to my IP Y, on interface Y.... Let me send it out the answer back on my Interface Z, but using IP address Y.. Doesn't Work that way....
If your sending out traffic from interface X, its going to have IP X on it be it a physical interface or a vlan interface...
So you have something borked in your isolation of vlans and or also your tagging..
With your tcpdumps you were doing - do them with the -e flag so you can actually see if traffic is tagged or not.. Also bump up the verbosity so can see the mac address of where that traffic was coming from and where it was set to go.
-
@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 ???
-
@bmeeks said in [How to check/enable antispoofing]
Hi bmeeks,
Yes, you understood correctly the scenario.
"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."
My firewall rules for the moment are allow any any (for testing purpose). How do you make the "out of state rule" that you are referring to? This feature should be present by default on firewalls as far as i know, but the pfsense acts like just a router in my case.
"I don't really see where anti-spoofing comes into play in this scenario." -> the antispoofing comes in by blocking the traffic that comes on the wrong interfaces. More exactly, in my case, the firewall receives the response from 10.100.100.7 towards the host 10.40.40.3, coming through its vlan 35 interface instead of coming through vlan 100 interface.
The firewall has interfaces in vlan 100 and vlan 35 and all the vlans that exist in my setup; he receives a packet from the vlan 100 subnet range, coming inbound in its vlan 35 interface (instead of vlan 100 interface), so it should say: "hey stop, you should be coming through interface 100, not interface 35. I don't have a route towards you through my interface 35, but i have through interface 100"It is the same thing as a firewall is receiving trafic from a public IP not on its WAN interface, but on one of its other interfaces (LAN, DMZ, whatever). It sees traffic from let's say 85.34.56.78 coming inbound in its LAN interface and says " hey you should be coming from my WAN interface, because i have a route(default one) to you through WAN interface, not through any of my other interfaces". and drops it.
This is reverse path check (called different from vendor to vendor, OS to OS, etc), in which the firewall does a check of the certain IP against its routing table and if he sees a match there, he forwards the packet, otherwise it drops it.
I hope i explained ok.
-
https://docs.netgate.com/pfsense/en/latest/book/firewall/rule-methodology.html
Anti-spoofing Rules
pfSense uses the antispoof feature in pf to block spoofed traffic. This provides Unicast Reverse Path Forwarding (uRPF) functionality as defined in RFC 3704. The firewall checks each packet against its routing table, and if a connection attempt comes from a source IP address on an interface where the firewall knows that network does not reside, it is dropped. For example, a packet coming in WAN with a source IP address of an internal network is dropped. Anything initiated on the internal network with a source IP address that does not reside on the internal network is dropped.
If you look you will see them...
[2.4.5-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep antispoof antispoof for $WAN tracker 1000001570 antispoof for $LAN tracker 1000002620 antispoof for $WLAN tracker 1000003670 antispoof for $TEST tracker 1000004720 antispoof for $NS1VPN tracker 1000005770 antispoof for $W_PSK tracker 1000006820 antispoof for $W_GUEST tracker 1000007870 antispoof for $W_ROKU tracker 1000008920 antispoof for $DMZ tracker 1000009970 [2.4.5-RELEASE][admin@sg4860.local.lan]/root: pfctl -vvsr | grep 1000002620 @65(1000002620) block drop in on ! igb0 inet6 from 2001:snipped:9::/64 to any @66(1000002620) block drop in on igb0 inet6 from fe80::208:a2ff:fe0c:e624 to any @67(1000002620) block drop in inet6 from 2001:snipped:9::253 to any @68(1000002620) block drop in on ! igb0 inet from 192.168.9.0/24 to any @69(1000002620) block drop in inet from 192.168.9.253 to any [2.4.5-RELEASE][admin@sg4860.local.lan]/root:So again ask how is it this traffic would be allowed.. State table would be for the other interface.. So this traffic would not be allowed in..
If you disabled antispoof, you would be wanting such traffic to happen..??
