- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-12-2012 02:45 AM
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
11-12-2012 10:52 AM
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
11-14-2012 07:03 AM
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
11-14-2012 02:51 PM
Just curious but what's dst: 192.168.0.2?
11-15-2012 01:03 AM
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
11-20-2012 08:50 AM
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)?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!