Are manual static NAT rules stateful in NG R55 AI?

[jrdld]

Experts please forgive me if this is a stupid question.

I had always understood (since v4.0) that if I had a static NAT rule like this:

Src=Any Dst=Public_Address Serv=Any Src=Original Dst=Hidden_Address(static) Serv=original

then I needed a reciprocal rule like this:

Src=Hidden_Address Dst=Any Serv=Any Src=Public_Address(Static) Dst=Original Serv=original

This is what you would see if you configure NAT for the Public_Address object and have the rules created automatically.

Is this still the case?

Here's why I ask. We have a mail system which resides on a firewalled service LAN. Originally users connected to it using its public address, which was translated to the hidden address. The NAT rules are configured manually as shown above. (Please don't ask why we don't use automatic NAT).

Then the mail admins started to tell some users to connect to the hidden address. A colleague added a security rule to allow this, but left the NAT rules as they were (as above). My understanding was that this would not work, since the reciprocal rule will translate the source of any reply from the hidden address, so that the user would see the reply packet come from the public address, even though he tried to connect to the hidden address. I.e:

SYN: User ------------------------------------->Hidden Address
SYN/ACK: User<-------Public Address (NAT)<---------Hidden Address
"Eh? Who are you?"

But this is not what happens. It works whether they connect to the public address or the hidden address. There are positively no other NAT rules that can affect this, so I can only imagine that the manual static rules are stateful, and my reciprocal rule is redundant. Can anyone confirm this?

Thanks.

JR

[RobertGraham]

Rules are always viewed from the point of connection initiation. That is,

A -> B XLATE C -> B

means that whenever A opens a connection to B the addr will be xlated. The packet on the return will also be xlated since the technology is stateful. This is what you are seeing.

However, if B wants to initiate a connection to C and have the packet end up at A, the rule above isn't sufficient. As long as the mail server doesn't need to initiate a connection to this other network - you're fine. In the case of an IMAP server that doesn't need Internet access and isn't the SMTP server is a perfect candidate for this one way static NAT situation.

Does that clear up the confusion?

[jrdld]

Thanks Robert.

So then the second rule really is redundant. This implies that when FW-1 creates automatic NAT rules, the second one will in most cases be redundant, since translated connections are usually only initiated in one direction.

For historical reasons, we have a lot of manual NAT rule pairs as shown above, most of which are for connections initiated only from one end. So if we wanted to cut our NAT rulebases down to size, we could use a single manual NAT rule in most cases, and automatic/reciprocal rules only where we have sessions that are initiated from both ends. Right?

JR

[northlandboy]

Yes, the second rule is redundant, if there are never any connections in that direction.

You could switch to automatic rules when you want bidirectional traffic, but I would just stick with manual rules, I'm not a big fan of automatic rules - those who've dealt with complex network setups with multiple firewalls and policies will know what I'm talking about.

[jrdld]

Thanks. That pretty much describes our situation, which is why we've always used manual.

This will really cut down our NAT rulebase.

JR