DNAT and IP-Filter do not block traffic

I have the same question. Need to block a full /24 brazil network that is spamming on our SG IPSec interface. DNAT and FW rules do not apply to this traffic.

UTM should automatically block hosts that have more than a definded No of bad requests per minute.

Hi LHerzog

You have to create a DNAT roule AND Kill the Connections at the Firewall-Console (SSH) with e.g. "conntrack -D -s 45.5.38.176".
Also, you need to do this for each IP Address in that /24 Network, i'm normaly using Excel to generate an IP List from 45.5.38.1 - 45.5.38.255 and then paste the Lines to CLI.

Regards,

Michael

and what would be the solution Sophos suggests in case you are really - i mean really - flooded with many of those packets?

Why is SG even answering to bad requests with IPSec notification replies?

Good question - please ask Sophos. If I had time I would have done already but these days I wish I had 8 arms like an octopus...

You may also try to set up 1 blackhole DNAT rule to drop all the IPsec connections and then create a new DNAT on top of it to allow IPsec connections from required source IPs(Branch/Client location).

Attaching few snapshots for reference.

==> Create 2 service definitions for TCP/UDP port 500 and port 4500

==> Use default IPsec service group and add above service definitions to it.



==> Create availability group under network definitions with allowed source IPs for IPsec connections. Add all remote location source IP to it.



==> Create 2 DNAT rules as shown below.



==> By configuring this you'll not have to add a single IPsec flooded IP in blackhole DNAT to drop its connection.

Let me know if you've any queries.

looks interesting. will try that.

Hi Yash,

this is not a real opportunity for remote access IPSEC because I cannot predict any random IP my roadwarriors might get by their ISPs.

It would be way more useful to allow the following setting on the UTM:

In "normal" mode:

Pluto should not answer to such malformed requests and wrong PSK - pluto should simply drop these attempts for not giving the aggressor an answer that he can try the next one.

In "debug" mode

When I have to debug sessions I should be able to switch on answering & logging

Cheers - Chris

That's true. in our case there is only static IPSec for Site-2-Site but in a case where IPSec is used for User VPN this is a no-go.

There are many approaches out there to automatically ban IPs that exceed a no of bad packets or connection attempts. Sophos is using these techniques only for bad logons. Thats a lack of security.

Guys, you've heard me say it before: best practice for IPsec and L2TP/IPsec remote access is to use X509 certs instead of PSKs.

Cheers - Bob

Would this change the behaviour of SG replying to malformed requests?

I don't think the "conversation" would ever get that far if using X509 certs.

Cheers - Bob

I am suffering with the exact same log entries. Sometimes the attacker will use the entire subnet of 255 IP's during the attempt to make an IPSec connection.  I opened a case with Sophos and they said they cannot block/deny these unwanted log entries.

Doing the Blackhole scenario seems never ending and the whitelist approach is a bit tricky as I have 100+ VPN entries including allowed subnets.  The question I have is WHY do they do it ?  Just to get a reply back saying "sending notification PAYLOAD_MALFORMED to 94.x.x.x" so they know they hit a firewall to later attack ??

What a waste of time !

I am suffering with the exact same log entries. Sometimes the attacker will use the entire subnet of 255 IP's during the attempt to make an IPSec connection.  I opened a case with Sophos and they said they cannot block/deny these unwanted log entries.

Doing the Blackhole scenario seems never ending and the whitelist approach is a bit tricky as I have 100+ VPN entries including allowed subnets.  The question I have is WHY do they do it ?  Just to get a reply back saying "sending notification PAYLOAD_MALFORMED to 94.x.x.x" so they know they hit a firewall to later attack ??

What a waste of time !