topic Re: IKE 500 in General Topics

IKE 500

infotech — Fri, 20 Jun 2014 13:42:44 GMT

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

Re: IKE 500

gswcowboy — Fri, 20 Jun 2014 14:36:12 GMT

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

Re: IKE 500

infotech — Fri, 20 Jun 2014 14:47:44 GMT

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

Re: IKE 500

ajbool — Fri, 20 Jun 2014 14:51:01 GMT

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.

Re: IKE 500

gswcowboy — Fri, 20 Jun 2014 14:53:18 GMT

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

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:01:32 GMT

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

Re: IKE 500

gswcowboy — Fri, 20 Jun 2014 15:05:41 GMT

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.

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:13:33 GMT

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)

Re: IKE 500

gswcowboy — Fri, 20 Jun 2014 15:15:03 GMT

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?

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:17:56 GMT

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

Re: IKE 500

HULK — Fri, 20 Jun 2014 15:19:08 GMT

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

Re: IKE 500

gswcowboy — Fri, 20 Jun 2014 15:20:14 GMT

Hulk may have hit the head on the nail w/ respect to the PBF rule.

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:23:28 GMT

Hulk

that command did not work for me it says invalid syntax

Re: IKE 500

HULK — Fri, 20 Jun 2014 15:26:15 GMT

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

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:28:39 GMT

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])

Re: IKE 500

HULK — Fri, 20 Jun 2014 15:46:17 GMT

Hello Infotech,

It seems the IKE packet is getting NAT'd. So, the remote-identity on the peer device should have the NAT'd IP, not the actual IP address-172.17.1.5.

Could you please confirm this. Also, could you please brief about the PBF rule.

Thanks

Re: IKE 500

infotech — Fri, 20 Jun 2014 15:55:26 GMT

My pbf is this

Source

source zone is DR-DMZ

Source address is 172.17.1.5

Source user - any

Destination/Application/Service

Destination address is - any

Application - any

Service is - any

Forwarding

Action - forward

Egress interface - ethernet1/3

Next hop is 66.94.196.107

Nat policy rule

Original packet

Source zone

DR-DMZ

Outside

Destination Zone

outside

Destination interface

any

Service

any

Source address

172.17.1.5

Translated packet

static IP

translated address 66.94.196.101

Bi-directional

Re: IKE 500

HULK — Fri, 20 Jun 2014 16:12:33 GMT

Hello Infotech,

Would it be possible to do a small test:

- Set the PAN as VPN initiator.

-Create a new NAT policy ( on the top of the policy table) to interface IP ( ethernet-1/3) only from source 172.17.1.5

-Initiate the VPN with CLI command >test vpn ike-sa gateway GTW-NAME

--Then check system logs for VPN.

Thanks

Re: IKE 500

infotech — Fri, 20 Jun 2014 16:19:55 GMT

Sure I can give that a try and will let you know the result when I have completed this test

Re: IKE 500

infotech — Fri, 20 Jun 2014 16:25:16 GMT

Where do you set the PA as intiator?