You can use Business Application Policies to configure NAT rules. Just choose the right zones and services and the NAT rules are created automatically.
adding masquerading to the policy is the same as creating a full-nat rule. that should only be necessary if the server you're forwarding traffic to isnt using your copernicus firewall as a gateway.
The reflexive rule is something else entirely. The idea is, that maybe you're forwarding traffic to a mail server from a particular public IP.
A reflexive rule would masquerade outbound connections from the server, to come from the same IP you're forwarding inbound traffic from. so if you forward traffic to a mail server from a.b.c.d, then outbound connections from the mail server will appear to come from a.b.c.d as well. It saves creating a specific SNAT or masquerading rule just for that purpose.
Hm. Wierd. The destination system on my internal network is using the Copernicus GW as it's default GW, yet it still only works if I turn on the Masquerading inside the rule.
So with these business rules, shouldn't return traffic automatically NATed? If an external server is addressing 192.168.1.1 and I use a business rule to forward to 10.10.1.1, should't the firewall automatically NAT the response packets from 10.10.1.1 back to 192.168.1.1? If so, then I still don't understand the Reflexive Rule piece.
And I still don't understand why I would have to turn on Masquerading in my business rule. So with that turned on, am I actually translating the IP of the external user/server to the IP of the Copernicus interface?
This is all very weird. Why can I not have a normal NAT rulebase like on any other firewall?
I'm not sure why you might need masq enabled, but the only other scenario I can think of, would be if you're connecting from the same subnet as your target server is in. In that case, and without the masq rule, your server would see the local source IP, and reply directly. Your client would expect replies to come from the firewall IP, and not the real server IP, so it would discard the reply from the server. Turning on masq would make the replies go back through the firewall, so your client gets the packet from the source he expects.
regarding the reflexive rule option, this isn't needed for reply packets. only for new traffic. If I want mail sent from my mail server to come from the same ip that I'm forwarding incoming mail on, then that's where a reflexive rule option makes this a bit simpler.
As for using just a regular nat rule, I understand it is different than UTM 9, and may be less obvious if you're just looking to create a DNAT rule. but we've seen problems with people coming from other vendor products, or who are new to security that struggle wit the concept of NAT. Different vendors use the term NAT differently, and sometimes even DNAT and SNAT are used with different meanings to what we use in UTM 9.
Also, we have more than one way to forward traffic to a firewall in UTM. DNAT is one way, but server load balancing is another. Users today, can be frustrated by creating a DNAT rule, then realizing they want to load balance traffic, so they need to start over and create a new server load balancing rule, or similarly in reverse. This combines both possible functions into one. Plus, it allows you to attach IPS and QoS policies directly to this rule, so traffic you forward can have specific security and limits/guarantees applied to it. These are typical tasks users want to do, but find very difficult (or impossible for IPS) in UTM9 today. we still need to do some work optimizing the policy creation screens to make the simpler tasks a bit easier, but putting all of this together does make more problems easier to solve.
I understand all that. I've been professionally dealing with firewalls sine 1996. I've seen them all, Checkpoint, Cisco, Juniper, Fortinet, Palo Alto, you name it [:)]
Ok let's try to get to the bottom of this:
Internal LAN: 172.16.16.0/24
Firewall IP: 172.16.16.16
LAN uses Firewall IP as default gateway
External WAN: 1.2.3.4
That's all there is right now. I want to forward incoming SSH traffic to 172.16.16.101.
I set up a business rule that has WAN as source zone, as hosted address I selected the WAN Interface.
I selected LAN as protected zone and used 172.16.16.101 as protected application server.
I set up port forwarding with TCP, external port 22, mapped port 22.
Everything else I left at its defaults.
Attempting to connect to 1.2.3.4 port 22 from the Internet times out.
I enable "Rewrite source address" and select the MASQ predefined NAT object.
Attempting to connect to 1.2.3.4 port 22 from the Internet: success.
I can't seem to reproduce it. I don't have an SSH server handy, so I'm forwarding RDP instead, and with no masquerading, connections work successfully when connecting from the wan side. There must be something else occurring here. can you see if anything interesting shows up in a packet capture? (system > diagnostics > packet capture)
Alan, I have to sincerely apologize. I just found an issue on my KVM host (which is running a virtualized Copernicus). For some reason the new default route I set on the host didn't fully apply. Some of my traffic was still being sent out through the old default gateway. Had to use tcpdump to figure it out.
I rebooted the KVM host and that fixed the issue. Now everything is working just like you described, even with MASQ turned off.
I guess this was a classic facepalm layer 8 problem.
Again, I apologize and thank you for trying to help. Appreciate it!
