DNAT and IP-Filter do not block traffic

Hi Chris69,

Thank you for reaching out to the Community! 

Have you configured any IPsec VPN remote gateway as a "Respond Only"? If yes, is this remote gateway used in any active IPsec connection?

Thanks,

Hi H_Patel,

yes I have configured some ipsec gateways as "respond only" but no, all these connection do match them.

It just takes 10-15min until new attacks try to get IPSEC-access, I cann kill them with conntrack and create new DNAT rules but this is not a game one could ever win that way.

There must be another way to protect the IPSEC gateway against more than 50 opened sessions from only one bad IP at the very same moment.

How should I handle this? I have seen this bevor but never that heavy like in these hours. 

Hi H_Patel,

yes I have configured some ipsec gateways as "respond only" but no, all these connection do match them.

It just takes 10-15min until new attacks try to get IPSEC-access, I cann kill them with conntrack and create new DNAT rules but this is not a game one could ever win that way.

There must be another way to protect the IPSEC gateway against more than 50 opened sessions from only one bad IP at the very same moment.

How should I handle this? I have seen this bevor but never that heavy like in these hours. 

Hallo Chris,

It looks like the best you can do now is make sure none of your "Respond only" Remote Gateways is used by an IPsec Connection that only uses a PSK.

Harsh, I didn't realize until now that this IPsec traffic could get past a DNAT.  Can you confirm that so I can update the Rulz (last updated 2021-02-16)?

Cheers - Bob

Hi BAlfson,

Inbound traffic would match the DNAT rule first before it gets to the IPsec module. Probably the DNAT rule isn't configured for all the source IP addresses. 

If there's inbound traffic from a specific country, I would say try the country blocking rule.

Thanks,

The DNAT rule do match after killing session via conntrack.
But unfortunately our UTM is flodded as hell and logs are filling up rapidly.

I am really finished - UTM-flodding and Exchange-armageddon at the same time.

aaargh!

Chris, please show pictures of the Edits of the telefonice and BLACKHOLE definitions with 'Advanced' open.

Cheers - Bob

It is no longer the telefonica-server, this I have successfully DNAT into 240.0.0.1 I think. But there are tons of connections I can  only get rid with a DNAT rule AND killing them via conntrack. Every single IP I DNAT and kill via conntrack is banned, so I think it should work - but it is useless as long they come from a hundred IPs again and again.

My ipsec.log is flushed like this:

Thanks - Chris

Hi

Country blocking does a small job - it became a little quieter. But still these packets do arrive - but from UK or USA which I cannot block generally.
Still of course I can catch every single IP, add them to my DNAT-rule and kill it witch conntrak. For a couple of minutes then everything is fine until they come from a different IP.

This is so odd...

Cheers, Chris

OK, Chris, let's look at the Edits of the IPsec Connection and Remote Gateway with 'Advanced' open.

I've never seen Alice in an IPsec log - what is the other endpoint?

Cheers - Bob

Thanks BAlfson

but I don´t think that these packets have anything to do with our site-to-site connections (although there are running some fine on the same gateway) thats why the answer to your question is not so relevant I guess. The site-to-site sessions do look very clear.

These requests are going to the endpoint for our roadwarriors, either plain IPSEC or L2TP.

Thats why I cannot block them all beacuse I could never know where my roadwarriors do come from.
Now I killed again 5 of these connections - and for 10min everything is quiet...as it was in former times most of the days...

Cheers, Chris

And one update:

I can really confirm that I do DNAT the right way because when I add an IP to DNAT-list to 240.0.0.1 and kill immediately via conntrack the last lines look like this:

udp      17 27 src=5.101.38.130 dst=x.x.x.x sport=19545 dport=500 packets=1 bytes=45 [UNREPLIED] src=240.0.0.1 dst=5.101.38.130 sport=500 dport=19545 packets=0 bytes=0 mark=1572864 delta-time=2 use=1

conntrack v1.4.2 (conntrack-tools): 71 flow entries have been deleted.

What does Sophos Support say about this, Chris?

Do you have the same problem if you use X509 certs instead of preshared keys?

Instead of IPsec or IPsec/L2TP, I've been configuring SSL VPN Remote Access on UDP 443 or 1443.  The OpenVPN clients work well where the Sophos Client can't work.

In any case, this isn't a fun or interesting battle for you.

Cheers - Bob