Default deny drops packets that are explicitly ALLOWED - antispoofing?

[buddystad]

Hello,

I created this topic after I did a some search on the topic of antispoof, but failed.

Here is the issue.

Problem:  The default deny drops packets that should be allowed by an explicit rule (src, dst, int, direction in...).

Bear in mind though, these dropped packets have the source IP on same subnet as of Int A,  and are received from int B. Is this because of the anti spoof in OPNsense? if this this is the case, is there a way to disable the anti spoof for this specific rule to allow these packets? (for whatever the reason, we need this asymmetric routing.)

Thanks

[Patrick M. Hausen]

Asymmetric routing bad. Fix your routing. 

The state that goes into the state table for allowed connections/flows explicitly contains the interface. If a service can be reached via two interfaces in two different networks/VLANs/whatever - why go through the firewall in the first place?

[buddystad]

Asymmetric routing bad. Fix your routing. 

The state that goes into the state table for allowed connections/flows explicitly contains the interface. If a service can be reached via two interfaces in two different networks/VLANs/whatever - why go through the firewall in the first place?

thank you for your reply. really appreciate it, but my questions were not answered.

1. is the feature of antispoof of OPNsense blocked those packets?
2. is there a way to circumvent it for a specific rule?

Don't get me wrong Patrick, get my sincere thanks to your reply.

[chemlud]

What the föck is "antispoofing" and what makes you think than OPNsense has a feature like that?

[Patrick M. Hausen]

What the föck is "antispoofing" and what makes you think than OPNsense has a feature like that?

Antispoofing means blocking any packet on any interface "in" with a source address that does not correspond to a route "out" that interface. Static or connected or learned dynamically.

E.g. by default blocking anything on LAN that does not have a source address of "LAN net".

On Cisco IOS this is activated with:

Code: [Select]

ip verify unicast reverse-path
As the IOS config statement suggests this does of course not apply to broadcast or multicast traffic like e.g. DHCP, but to unicast only.

It's a useful feature present in many firewalls.

@buddystad

No, OPNsense does not have a general anti-spoofing mechanism. But as I wrote it will cut connections if asymmetric routing is involved. Since asymmetric routing is generally a bad idea, best recommendation is to eliminate it from your network.

[buddystad]

@chemlud, what is the word 'föck'? 

@Patrick,

I agree with you about the symmetric routing being sub-optimal. Anyhow, the bad thing will have remain in place for a while, unfortunately.

However, I did a test where the OPNsense did not block the returned the packets even though these packets were received from another Interface than. the difference in this test scenario was that the OPNsense has the flow in the state table.

So may I draw a conclusion that the OPNsense does not simply block/cut the traffic because of the asymmetric routing, but check the state table first. If there is a state entry having the tuple of src and dst, port... the OPNsense would pass them even though the returned traffic comes in from another interface.

I am guessing.

Again, anyone can answer my second questio (is there a way to circumvent the "asymmetric cut")?

thanks

[viragomann]

Again, anyone can answer my second questio (is there a way to circumvent the "asymmetric cut")?

If the request packet passes OPNsense, but no the response, you can masquerade the traffic on the outbound interface.

Less ideal: You can add add rule to allow the traffic with "sloppy state" in the advanced options of the rule.

[buddystad]

Hello viragomann,

Thank you for your ideas.

I tried adding a sloppy-state rule to allow the packets, but to no avail. I would believe the sloppy-sate still checks the state table, even though without checking the sequence#, as per the online help.

Finally I fixed the problem by adding a static route to make the return packets get routed back to the OPNsense box that handles the inbound packets and mains the original entry in the state table.

I believe that dropping returned packets due to the asymmetric routing is a builtin security feature like many other firewalls do. I am wondering how much would it hurt if OPNsense team could add a switch to turn it off in some particular scenarios?

thanks to all who gave some hints, and to the viewer as well.

[buddystad]

Oh, maybe the state type of NONE is the switch  to turn it off.

good day