issue with uturn nat, please help!

[mstevenson]

Hi All

I have a u turn nat rule and security policy in place that has been working fine to allow internal access to the external url of our exchange owa and now it has stopped working - nothing has changed on the firewalls or on the exchange system that could explain the problem.

The u-turn nat rule is setup as follows

Source Zone: L3_Inside

Destination Zone: L3_Outside

Destination Address: 89.238.148.200

Source Translation: Dynamic IP and Port (Correct interface and IP selected)

Destination Translation: 172.16.0.77 (internal address of OWA cluster)

Security rule for the u-turn nat:

Source Zone: L3_Inside

Destination Zone: L3_Inside

Destination Address: 89.238.148.200

Normal external nat rule for the OWA setup:

Source Zone: L3_Outside

Destination Zone: L3_Outside

Destination Address: 89.238.148.200

Destination Translation: 172.16.0.77 (internal address of OWA cluster)

Security rule for the normal external OWA rule:

Source Zone: L3_Outside

Destination Zone: L3_Inside

Destination Address: 89.238.148.200

I can see traffic passing through the firewall using the u-turn nat rule but the application column just reports as incomplete? any ideas would be great as i cant work out what could be wrong. We have multiple nat and u-turn nat rules setup to allow access to other external urls internally and these work perfectly fine and these are setup in exactly the same way.

Thanks

Matt

[mbutt]

Hi Matt,

Look for the session by using the following commands

show session all filter source

  <ip>  <ip>

and then look at the session details by using the following commands

show session id

  <value>  <1-2147483648> Show specific session information

Check if you see both way traffic on that particular session.

Also you can do a packet capture from the GUI to look the traffic.

Usually if you are getting application as incomplete either it is uni directional traffic or there was not enough traffic for it to determine the application.

Also you can see the global counter to check if any traffic is getting dropped.

so can setup the filter in the GUI under Monitor------>packet capture.

Then on the CLI after enabling the filters run the following command to see what counters are incrementing for  the interested traffic.

show counter global filter packet-filter yes delta yes

Let us know if this helps.

Thanks

Numan

[mstevenson]

Hi Numan

Thanks for your reply and advice, i have posted the output of the show sessions can you take a look and see if it looks right.

Matthew@Altrincham_Primary(active)> show session all filter source 172.16.12.25

--------------------------------------------------------------------------------

ID      Application    State   Type Flag  Src[Sport]/Zone/Proto (translated IP[Port])

Vsys                                      Dst[Dport]/Zone (translated IP[Port])

--------------------------------------------------------------------------------

20456   undecided      ACTIVE  FLOW  NB   172.16.12.25[49469]/L3_Inside/6  (192.168.0.2[24823])

vsys1                                     89.238.148.200[443]/L3_Inside  (172.16.0.77[443])

17465   undecided      ACTIVE  FLOW  NB   172.16.12.25[49468]/L3_Inside/6  (192.168.0.2[4005])

vsys1                                     89.238.148.200[443]/L3_Inside  (172.16.0.77[443])

Matthew@Altrincham_Primary(active)> show session id 20456

Session           20456

        c2s flow:

                source:      172.16.12.25 [L3_Inside]

                dst:         89.238.148.200

                proto:       6

                sport:       49469           dport:      443

                state:       INIT            type:       FLOW

                src user:    altrincham\administrator

                dst user:    unknown

        s2c flow:

                source:      172.16.0.77 [L3_Inside]

                dst:         192.168.0.2

                proto:       6

                sport:       443             dport:      24823

                state:       INIT            type:       FLOW

                src user:    unknown

                dst user:    altrincham\administrator

        start time                    : Wed Nov 14 15:01:13 2012

        timeout                       : 5 sec

        total byte count(c2s)         : 132

        total byte count(s2c)         : 0

        layer7 packet count(c2s)      : 2

        layer7 packet count(s2c)      : 0

        vsys                          : vsys1

        application                   : incomplete

        rule                          : U-Turn Webmail SEC

        session to be logged at end   : True

        session in session ager       : False

        session synced from HA peer   : False

        address/port translation      : source + destination

        nat-rule                      : U-Turn Webmail NAT(vsys1)

        layer7 processing             : enabled

        URL filtering enabled         : False

        session via syn-cookies       : False

        session terminated on host    : False

        session traverses tunnel      : False

        captive portal session        : False

        ingress interface             : ethernet1/2

        egress interface              : ethernet1/2

        session QoS rule              : N/A (class 4)

Thanks

Matt

[gswcowboy]

Just curious but what's dst: 192.168.0.2?

[mstevenson]

192.168.0.2 is the internal ip address of the L3_Inside interface the firewalls sit in a separate VLAN to the main internal network with routing between the VLANs (its to cope with the ARP limit of the palo) its the dynamic IP and port address for the L3_Inside interface.

Matt

[mstevenson]

bump

[mikand]

When you setup security rules in PA for NATed traffic the guideline is:

srczone: <prenat srczone>

dstzone: <postnat dstzone>

dstip: <prenat dstip>

which you seems to have followed according to your first post.

Now verify routing...

If both client and server sits on the same segment you might end up with:

1) Client sends SYN to PA who DNAT the traffic back to L3_inside but another dstip (the ip of server).

2) Server sends SYN+ACK directly to client without passing through PA for its return traffic (since srcip isnt modified).

There are several fixes for the above situation...

One is of course to not only DNAT (destination nat) but also SNAT (source nat) the packets going client -> PA -> server.

This way the server will return the packets back to the PA who will in turn return the packets back to the client.

However you already seem to do this...

Another way is of course to set servers on their own VLAN and by that their own zone.

I wonder if you by mistake have setup a bi-directional nat-rule or something that might interfer with the above OWA-traffic?

Because bi-directional is only needed regarding how the session is being setup. For example the above doesnt need a bi-directional rule (because the OWA doesnt need to start sessions against the clients, its the clients who starts the sessions against the OWA).

I would setup a PCAP on the switch which your PA L3_inside is connected to just to verify how your OWA actually is returning its traffic (or not).

Speaking of OWA and you say that you didnt do a thing I would also verify how the SSL/TLS is being setup.

Microsoft issued a mandatory update for all its products in october I think where they drop support for 1024 bits and below when it comes to SSL/TLS - perhaps its something like this which suddently starts to give you the above problems (meaning the fault is not on the network layer but on the application layer or such)?