VPN IPsec still turned up on remote side - filling up my logs

Hi Dave,

You want #2 in Rulz (last updated 2019-04-17).

Cheers - Bob

Hi Bob,

Rule #2 has VPN's at item 6. Are you saying that I need to create a DNAT (item 5) to somehow "block" the packets coming in so I do not see them in the VPN IPsec logs ?

I do not have IPS on.  How would I use a DNAT to block traffic coming in from a Public IP and then drop or reject it?

Thanks!

Dave

Yes, Dave, a "blackhole" DNAT that sends the incoming packets to Never-Never Land.  Something like...

 DNAT : {FQDN of offending IP} -> IPsec -> External (Address) : to {240.0.0.1} : w/auto Firewall rules

Cheers - Bob

I am having a bit of difficulty creating the "Blackhole" DNAT correctly but will work on this as it has been discussed so many times in the forum.

But - when I create this correctly and also add a rule to drop all traffic to the blackhole address of 240.0.0.1, I should NOT see any traffic in my IPsec logs with this Public IP attempting to connect to a VPN that is disabled on my end - is that correct ?

Thanks again!

Dave

I am having a bit of difficulty creating the "Blackhole" DNAT correctly but will work on this as it has been discussed so many times in the forum.

But - when I create this correctly and also add a rule to drop all traffic to the blackhole address of 240.0.0.1, I should NOT see any traffic in my IPsec logs with this Public IP attempting to connect to a VPN that is disabled on my end - is that correct ?

Thanks again!

Dave

Correct, Dave - that's why you want to select automatic firewall rules.  If you still have an issue, show a pic of the Edit of the DNAT.

Cheers - Bob

Simple concept -but I still see hundreds of lines in IPsec Logs showing this Public IP trying to establish a VPN.  Am I somehow "allowing" this incoming traffic and defeating the DNAT ?

LOGS:

pluto[6415]: packet from 66.111.222.66:500: received Vendor ID payload [RFC 3947]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [16f6ca16e4a4066d83821a0f0aeaa862]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
pluto[6415]: packet from 66.111.222.66:500: received Vendor ID payload [Dead Peer Detection]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [FRAGMENTATION]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [FRAGMENTATION c0000000]
pluto[6415]: packet from 66.111.222.66:500: ignoring Vendor ID payload [8299031757a36082c6a621de00000000]
pluto[6415]: "L_for dgrasso"[4] 66.111.222.66 #21015: responding to Main Mode from unknown peer 66.111.222.66

What happens if you remove "Any" from "EXT Address Group dg"?

If that solves the problem, go back to the Rulz post and check out the diagrams at the bottom that show the difference between the INPUT and FORWARD chains.

Cheers - Bob

Removed "Any" - no change.

I think we are into that area when a reboot fixes everything?

I completely removed any remnant of the old VPN from my side: VPN Gateway / Connection, etc.

Yet the logs indicate my end is still trying to communicate with the WAN Ip?

"L_for dgrasso"[11] 66.111.222.66 #44137: responding to Main Mode from unknown peer 66.111.222.66

#44137: NAT-Traversal: Result using RFC 3947: no NAT detected
#44137: next payload type of ISAKMP Identification Payload has an unknown value: 100
#44137: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)
#44137: sending encrypted notification PAYLOAD_MALFORMED to 66.111.222.66:500
#44137: next payload type of ISAKMP Identification Payload has an unknown value: 100
#44137: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)

On of these days when I get "spare" time, I will test the blackhole DNAT when I have complete control of both sides.

I am going to move this firewall by April to a new ISP so the packets will stop if I still can't get them to turn down the VPN on their end.

I appreciate your time on this but sometimes its a game of diminishing returns and I don't want to waste any more of your time.

Thanks Bob !