06-20-2014 06:42 AM
Here is some traffic being sent from my DMZ to the internet and I am trying to determine whats happening. How would the community read this information
Session 192980
c2s flow:
source: 172.17.1.5 [DR-DMZ]
dst: 199.169.208.244
proto: 17
sport: 500 dport: 500
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
pbf rule: Fedline 12
s2c flow:
source: 199.169.208.244 [Outside]
dst: 66.94.196.101
proto: 17
sport: 500 dport: 500
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
start time : Tue Jun 17 14:25:00 2014
timeout : 600 sec
time to live : 600 sec
total byte count(c2s) : 7012782
total byte count(s2c) : 0
layer7 packet count(c2s) : 23853
layer7 packet count(s2c) : 0
vsys : vsys1
application : ike
rule : Rule 6
session to be logged at end : True
session in session ager : True
session synced from HA peer : False
address/port translation : source + destination
nat-rule : Fedline_DR(vsys1)
layer7 processing : completed
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : vlan.999
egress interface : ethernet1/3
session QoS rule : N/A (class 4)
session tracker stage l7proc : ctd err sw
06-20-2014 07:36 AM
172.17.1.5 is initiating ike session to 199.169.208.244 and it's hitting sec and nat policy as defined. The following below indicates the lack of a response from the destination peer IP as it probably doesn't have GW (ike/ipsec) configured for the initiating host in question.
layer7 packet count(c2s) : 23853
layer7 packet count(s2c) : 0
06-20-2014 07:47 AM
My vendor is the peer and I told him the exact thing you did that it was making it to them (the peer) and not being accepted by the peer so the ipsec tunnel was not being established
06-20-2014 07:51 AM
If you need to NAT your IPsec session, you're going to need to use IPsec NAT Traversal (aka NAT-T). With NAT-T all traffic will be on UDP port 4500 (usually; Global Protect seems to use udp/4501).
See if you can enable an option NAT Traversal on both ends of the IPsec connection.
Security Policy wise; if you're using the 'ipsec' application for your security rules on your PA firewall you should be fine. If not; ensure you have 'ipsec-esp-udp' permitted.
06-20-2014 07:53 AM
confirm NAT-T is required and enabled. here's an excerpt log from another vendor where it wasn't supported. confirm if it's supported on their end.
VPN IKE NAT Discovery : Peer IPSec Security Gateway doesn't support VPN NAT Traversal
06-20-2014 08:01 AM
I will check that out , this is at our DR site but it is working currently on our Main site with the exact same configuration that is why I am baffled
06-20-2014 08:05 AM
you could enable packet-diag filters and perhaps flow basic and pcaps to give some more granular insight(are we dropping packets, etc) but would err in the side of caution and do this during off peak hours.
06-20-2014 08:13 AM
I have done some pcap and it show no drops and that the traffic is transmitted into the internet but no response and no ipsec tunnel (udp 4500)
06-20-2014 08:15 AM
if pan is not getting the s2c traffic back in return, perhaps vendor can provide logs/data(pcaps) related to the ike initiated traffic from your end to help w/ the analysis?
06-20-2014 08:17 AM
That would be awesome but they think its getting lost in the internet, saying it my ISP's fault cause they say they don't seeing any from us
06-20-2014 08:19 AM
Hello Infotech,
It seems the traffic is forwarded through a PBF rule( Fedline 12), So the packet should be received through the same path.
Could you please check if there is any existing session for ike has been stuck (discard state) between 2 gateways for IKE/500.
>show session all filter port 500
Thanks
06-20-2014 08:20 AM
Hulk may have hit the head on the nail w/ respect to the PBF rule.
06-20-2014 08:23 AM
Hulk
that command did not work for me it says invalid syntax
06-20-2014 08:26 AM
Sorry for the typo. Use this CLI command: > show session all filter destination-port 500
As Nato mentioned before, are you expecting the traffic to be forwarded through the PBF rule...?
Thanks
06-20-2014 08:28 AM
here is the result
--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
188239 ciscovpn ACTIVE FLOW 66.94.196.107[500]/Outside/17 (66.94.196.107[500])
vsys1 173.161.59.109[500]/Outside (173.161.59.109[500])
193039 ike ACTIVE FLOW NS 172.17.1.5[500]/DR-DMZ/17 (66.94.196.101[500])
vsys1 199.169.240.244[500]/Outside (199.169.240.244[500])
594 ciscovpn ACTIVE FLOW 66.94.196.107[500]/Outside/17 (66.94.196.107[500])
vsys1 66.94.196.100[500]/Outside (66.94.196.100[500])
192980 ike ACTIVE FLOW NS 172.17.1.5[500]/DR-DMZ/17 (66.94.196.101[500])
vsys1 199.169.208.244[500]/Outside (199.169.208.244[500])
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!
