Announcement

Collapse
No announcement yet.

Dnat... when does it get used... and how can I stop it...

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dnat... when does it get used... and how can I stop it...

    Can anyone explain to me why the following two inbound connections differ in that one is dnat'd and the other is not? (I assume dnat = double NAT ??)

    We have a firewall with multiple external IP's allocated (alias's against the external interface).
    Two internal email servers operate on differing IP addresses and have separate inbound tunnels defined. Except for the IP addresses, the tunnels have the same options selected.. yet the connections through the firewall differ as below..


    Jun 1 13:40:02 pri=5 msg="Close inbound, NAT tunnel" proto=25/tcp src=1.2.3.4 srcport=63338 nat=6.7.8.9 natport=25 dnat=10.1.1.254 dnatport=63338 dst=10.1.1.30 dstport=25 rule=136 duration=23 sent=2122 rcvd=3360 pkts_sent=23 pkts_rcvd=15

    Jun 1 13:38:42 pri=5 msg="Close inbound, NAT tunnel" proto=25/tcp src=1.2.3.4 srcport=33606 nat=6.7.8.10 natport=25 dst=10.1.1.35 dstport=25 rule=200 duration=25 sent=511 rcvd=877 pkts_sent=8 pkts_rcvd=8



    The issue this creates is that server 10.1.1.30 sees all inbound connections as originating from 10.1.1.254... which defeats any IP lookup or RBLS queries from having any effect....

    Can anyone explain why this might be? (I thought it might be because I had selected 'Hide Source' against one of the tunnels.. but this is NOT that case..)

    Cheers

  • #2
    Hi Matt

    You were correct. Hide source is what causes this behavior. Inbound tunnels by default do not mask source address. Only when you select hide source does it mask the IP with the gateway address.

    Keep in mind that changes on the firewall will not take effect on already established connections, but all new traffic will show the change. If needed, flush any active connections and your logs should no longer show the dnat case.

    Hope this helps.

    Comment


    • #3
      Thanks Rick,

      I thought it was.... The frustrating thing however is that both inbound tunnels have the 'Hide Source' check box cleared!!
      I have looked at all the other inbound definitions as well, none of them have 'Hide Source' selected... so its a bit of a mystery still....

      Is there any way to tell exactly what rule is being used?? (The firewall log refers to 'rule=136' but I'm not sure what this means.. inbound tunnel 136 has nothing to do with SMTP...)

      Cheers

      Comment


      • #4
        For reference, paste the full log message. The full log message will contain the type of policy which was matched and then this can be matched to rule 136 for whatever policy type allowed this traffic. With regards to Rick's point, have you navigated to [Monitor -> Activity -> Network -> Connections] and ensured that all SMTP connections have left the firewalls state table? You may force these connections to close by using the Flush button on this page.

        Comment

        Working...
        X