DNAT rule goes thru and drop in the same moment - that drives me crazy!

You have bound one of the objects to an interface. Remove it and test again. 

Hi MasterRoshi,


thank you for your hint.


Before I create the forwarding DNAT rule I changed each destination of my firewall rules for internet access from "Any" to "Internet IPv4 & Internet IPv6" (for that I created the custom Network group "Internet").


Because of your hint I checked my definitions and see, that the built-in definition "Internet IPv4" is bound to "External (WAN)" !? Could this cause the error?

Hi Moeppi,

It is more likely the destination object that has the interface binding (Internal Mail Server). The default IPV4 internet object is like that on purpose and cannot be changed. 

... the "Internal Mail Server" have no interface binding.

Most likely it is the internet IPV4 object then, I have never seen this being used in a DNAT before and have not tested it. 

Can you try with ANY and let us know if you still see the firewall drops in the logs after the initial connection hits the rule?

Hi

Regarding the Internet IPv4 object in a DNAT rule, perhaps I'm misinterpreting the above comments (more than likely, with me having earlier having consumed a [sizeable] Pickering's Gin and tonic, followed by the best part of a bottle of [v. cheap] Rioja) but just in case it's of any use to the discussion, I have also used the Internet IPv4 object in a DNAT rule, which in the below illustrated case, facilitated external SSH access (using a 'funky' port, shown as the service 'Beacon -Admin' in the below screen-shot) to be re-directed to an internal Raspberry Pi (listening on the standard SSH port) and the last time that it was required for action (admittedly, about a couple of years ago) it all seemed to work, okay. That said, my remotely located friend had also been on the large G&T's, so perhaps we just imagined it as all working okay! :P

The below being conceptually similar to that shown in the image at the head of this thread:

Of course, apologies if I have completely misinterpreted the last couple of posts (and if so, I solemnly promise to in future buy a higher grade Rioja).

Kind regards, Briain

Hmm.. interesting so lets forget about the binding for a second since its not an issue anymore according to the initial post and internet ipv4 seems to be fine. 

To me this looks like when your WAN goes down every 24 hours and comes back up, the iptables entries for the DNAT are not coming back with it but it does when you toggle the rule. 

This would need more in depth investigation, I would suggest opening a support case. 

Tomorrow evening - from a remote site - I'll test that the IPv4 object DNAT rule still actually works (the last time it was used was a couple of years ago) and I'll report back.

Bri

Tomorrow evening - from a remote site - I'll test that the IPv4 object DNAT rule still actually works (the last time it was used was a couple of years ago) and I'll report back.

Bri

Hi

Just a quick note to say that as promised above, I did some 'commissioning' checks on my DNAT rule (to check that using the 'Internet IPv4' object still worked) and also some tests on the double-NAT aspect of my installation.

As I am using double NAT, I first opened a port in the ISP connected router (for the below example, lets say it was port 23456) to the UTM's WAN address (which is on the LAN side of the ISP router; actually 192.168.6.2) then in the UTM, I switched on the below DNAT rule (same image as is shown a few posts back) where the ISP router and UTM rule entry details are listed below (I'm writing it up in detail, just in case any new home UTM users chance across this thread when setting things up):

ISP router settings:
LAN side 192.168.6.0/24
Gateway 192.168.6.1
UTM MAC/IP bound to 192.168.6.2

UTM DNAT rule settings:
Using service = 'Beacon Admin' is port 23456
Going to = WAN (LAN4) (UTM WAN set to DHCP, MAC/IP bound to being 192.168.6.2 within the ISP router)
Change destination to = a Raspberry Pi - on its own VLAN - at 10.90.90.2
And service to = port 22

With the above set up as described, when using the 'publicly exposed' address to access the R Pi from within my own network (so from a machine on the LAN side of UTM, I used ssh pi@mydomain.ddns.net -p 23456) I successfully gained access, then when using password access (rather than RSA keys) and incorrectly entering the password a few times, it triggered fail2ban (set up on the R Pi), with the ISP router's [gateway] IP address being banned (incidentally, just to give the full picture of the test setup, the Pi and the machine I accessed it from are also sitting on different 'UTM created' VLANs, with no inter-VLAN UTM firewall rules enabled).

fail2ban> status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:    0
|  |- Total failed:    0
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned:    1
   |- Total banned:    1
   `- Banned IP list:    192.168.6.1
fail2ban> set sshd unbanip 192.168.6.1
192.168.6.1

Having unbanned 192.168.6.1, I then visited a remote site (golf club bar with public WiFi) and I successfully accessed the R Pi (again, using ssh pi@mydomain.ddns.net -p 23456) then after a meal and several glasses of nice wine, I tried using incorrect passwords (triggering fail2ban), then when back home (and looking at the Pi), this time fail2ban showed the golf club's public IP address as being banned:

fail2ban> status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     4
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     2
   `- Banned IP list:   123.123.123.123 (obviously, I've obfuscated their real address)

So I am happy that everything is still working as it did when I first set all this up (a couple of years ago) and it was good to verify that when accessing it remotely, the R Pi's iptables/fail2ban see (and thus ban) the public IP address of the remote, nefarious wine-drinking client (as opposed to my ISP router's gateway address).

Kind regards,

Briain