How to check/enable antispoofing
-
@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.
