External and internal NAT for different ports

Hello Matthias,

spontaneous idea: the port is used by one of the (web-) services on the firewall itself.

I usually use 8443 for "User-Portal", can you check this?

Hello Philipp,

thanks for your answer. I can confirm that the port is not in use. We have a range of static ipv4 addresses and the one I used for the wifi controller isn't in use for anything except the two ports I mentioned.

Kind regards,

Matthias

Hello Matthias,

I am not quite sure about this, if I got it right...

Can you check your settings.or post an (edited) screenshot of "Management/User Portal/Advanced/Network settings" ?

Or maybe you use this port for SSL-VPN?

Info: If you have one physical LAN-port going to "WAN" and your "range of static ipv4 addresses" is setup with "additional addresses", then a port you use for one of these services is in use on ANY of these additional ip addresses as well.

Hello Philipp,

I double checked it. We use port 55555 for web admin, port 4446 for userportal and 443 for ssl vpn. Yes, the static ip addresses are setup with "additional addresses". But why should a port that we use on one of these addresses also be used on the other ones? We choose the different interface addresses for the services like for ssl vpn we use "WAN .147" because it is 443 and we use it with other addresses too (for other services).

I also checked it with telnet. It can't connect with 8443 which means there is nothing configured or?

Here are the screenshots: 

Kind regards,

Matthias

Helo Matthias,

again: Can you please check your settings.or post an (edited) screenshot of "Management/User Portal/Advanced/Network settings" ?

You can't test with telnet, if the service is using SSL-encryption.

And, believe me: these "web-service" ports are active on every additional addresses, when you allow that HW-interface for access.

Hello Philipp,

here is the screenshot: 

Thanks in advance.

Kind regards,

Matthias

OK, I see. I can only think of a provider, that blocks "unusual" ports like 8443...

Anybody else has an idea?

OK, I see. I can only think of a provider, that blocks "unusual" ports like 8443...

Anybody else has an idea?

Hello Philipp,

I think you misunderstood me. I don't want to open the port 8443 on the WAN interface. We have 4 ports for the wifi controller. TCP 8443, TCP 8080, UDP 3478 and TCP 8880. We already created a NAT for 8080, 3478 and 8880 which points to the wifi controller in the DMZ. These are the ports that the APs from e.g. offsite locations need to communicate and register at the wifi controller. Port 8443 is the web ui port for the wifi controller. But we don't want the web ui to be accessable from outside the company network. So I tried to make DNAT/Full NAT rules: Internal (Network) -> TCP 8443 -> wifi.*.de (external IP address) / Destination translation to internal IP of the server in the DMZ and no service change because it is still 8443. 

Here is a screenshot where you can see what I mean:

So basically if someone does a nslookup on wifi.*.de from the internal network he gets the public ip instead of the internal ip because I made an a record in the domain dns for it so that all the APs that are trying to connect to it go through the WAN. I did that because we have different offsite locations and we don't want to route the DMZ network through it (but they get the domain dns).

When I look into the logs and I try to access the web ui from the internal network I can see that the packages get dropped by default rule and the destination is wrong (it shows the public ip instead of the internal ip because I go over port 8443 and it should be the internal ip of the wifi controller in the DMZ).

I hope this helps.

Thanks in advance!

Kind regards,

Matthias

Hallo Matthias and welcome to the UTM Community!

You need a Full NAT where the Source is changed to "Internal (Address)" or an Additional Address on the Internal interface.

Cheers - Bob

Hello Bob,

thanks for your answer. I already tried that but it didn't work. I just did it again to verify that I didn't make a mistake. 

This is my Full NAT:

Firewall logs still show default drop with destination {public ip}:8443.

Kind regards,

Matthias, please copy a default drop line from the Firewall log file (not the Live Log).  If you prefer, obfuscate IPs like 212.XX.YY.22, 10.X.Y.100, 192.168.X.200 and 172.2X.Y.51. That lets us see immediately which IPs are local and which are identical.

Cheers - Bob

Hey Bob,

here is a line from the log: 

2021:10:21-15:05:47 fw-1 ulogd[11751]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="lag0.2" srcmac="*removed*" dstmac="*removed*" srcip="192.168.X.215" dstip="212.X.Y.148" proto="6" length="52" tos="0x02" prec="0x00" ttl="127" srcport="63896" dstport="8443" tcpflags="SYN" 

Here you can see that he tries to access the wifi controller with the public ip instead of the DMZ ip even though the Full NAT rule is activated.

Thank you in advance.

Kind regards,

Matthias

Philipp, I looked at his log line below and his Full NAT.  The packet should not have been dropped.  What am I not seeing?

Cheers - Bob

Hi Bob,

what is this: initf="lag0.2"