FTD inspection on Hairpin L2L VPN

[cshackel77]

We have a customer who will be implementing a 2110 FTD appliance at their HQ internet edge with full TMC.  They have a non firepower legacy ASA at a branch location.

They desire to establish a L2L VPN between the two, and backhaul 100% of the branch traffic to the headend 2110 including internet access. The VPN will terminate on the outside interface of the 2110, so it will be a hairpin for the traffic going to the internet.  They want to know if the 2110 can apply FTD inspection (specifically URL filtering) for the remote branch local networks/users.  I cannot find examples or specific validation that this would work.

Anyone know?  I know Umbrella is the perfect use case for this, but that's not on the table.

[jtzortza]

A couple of Qs:

Mainly need ot understand the VPN environment, from the inspection point of view, all Advanced inspection processes will be available on decrypted VPN traffic.

What models are remote ASAs? version?

Do remote ASAs use Public Internet addresses to terminate L2L on the outside i/f of 2110?

Does customer has static IPs? All dynamic IPs? mix?

Plan to use on-box Firepower Device Manager for configuring the 2110?

[cshackel77]

FMC will be used to manage the 2110.

The firewall at the branch location is an ASA5506, code 9.6 (no firepower services licensed).

The L2L tunnel between the two is over the internet, with the public egress IP being the peer on each interface.  The inside networks behind each firewall are static.  The customer desire is to match the branch network and 0.0.0.0 on the 2110 side to backhaul 100% branch traffic to the HQ 2110, and then for the branch to internet destined traffic, hairpin off the 2110 via the HQ internet line (i.e. hairpin on the outside interface).

The unknown question is can and how would the 2110 provide FTD inspection (specifically URL filtering policy) to the branch traffic?  The FTD guide is clear that inspection is done post decryption (obviously), but there is nothing I can find in CVD or elsewhere that covers how to account for traffic that is ingressing/egressing the same interface (the hairpin on the 2110 outside int).

[bkastor]

Did you ever get this working? I have a similar case, but it is with an ASA (and the FP Module with URL Filtering) and Anyconnect clients. I know from ASA experience that I can hairpin full-tunnel vpn clients (so their default route is the ASA they are connecting to).. but I am just guessing that it is going to work hairpinning AND seeing URL inspection from the FP Module.

I will find out in about 2 weeks when we do it.. But I would love to hear from someone that can verify this works..

[cshackel77]

We are still working with the customer to schedule the install now that their 2110s have arrived. Cisco has confirmed to me it will work in FTD, so I assume it would work in ASA+FP mode as well.  I'll update this thread once we have it implemented, but will probably be after your time frame.

[bkastor · Accepted solution]

Very simple testing is completed and it works great..

Anyconnect 4 client, ASA 9.7, Firepower 6.2 and a basic full tunnel with hairpin.. seems to block URL connections just fine. I manually specified facebook to block.. and then they received their URL license.. so by reputation worked as well. 

I haven't done any IPS testing, but I am assuming it works based on the URL filtering.

If you need any of the relevant config, please let me know. Thanks!!

[cshackel77]

Brian,

Thank you for the validation. We are still waiting on schedule for install for our customer with this scenario.  I let my install engineer know it works.  I'll reach out if he needs any config references but he feels like he knows what to do.

thanks again!

[FSBAdminAccount2129]

Do you have example of the NAT used on FTD to make this work.... Working on same issue and "hairpin" NAT is not working

[deyster94]

Did you get hairpinning to work in FTD?  I have the S2S VPN built between the two FTD appliances, internet traffic is being sent from the remote branch to HQ, but it doesn't seem to work.  I know in the ASA we had the same-security-traffic permit intra-interface command, but I can't get that to deploy in flexconfig.

TIA,

Dan

[cshackel77]

We have not done that customer deployment yet that requires it.  Brian said he was able to up above.  Maybe he can share the config.

[bkastor]

Hi deyster94,

We did have this working.. but have pulled it apart (political.. you can almost hear the gasp at that!).

Anyway, I have just labbed up an example here (I only have 1x5512 at the moment). My example just uses a vpn client to get into a 5512 with FP services, not FTD... so not a perfect example, but should not be much different than your situation.  Here is the relevant config:

same-security-traffic permit inter-interface !<- I know that isn't needed, but just putting down what I have..

same-security-traffic permit intra-interface

!

object network WORK

subnet 10.111.111.0 255.255.255.0

!

object network VPN_CLIENT

subnet 10.111.222.0 255.255.255.0

!

nat (inside,outside) source static HOME HOME destination static VPN_CLIENT VPN_CLIENT no-proxy-arp route-lookup

!

object network WORK

nat (inside,outside) dynamic interface

!

object network VPN_CLIENT

nat (outside,outside) dynamic interface

Otherwise, the rest of this is the same as a site to site.. With this config, I can do any group policy or pool.. which shouldn't change the outcome.

After this is in place, I can use the FP services to do things like No split-tunnel (so tunnel all) and then turn on URL filtering, like forcing them through the device, then back out again. Should be the same with a site to site..

Let me know if that helps...

[deyster94]

Brian,

Thanks for the information.  I tried your suggestions in my FTD lab environment, but without any luck.  If I do a packet tracer, this is what it the output looks like:

Phase: 1

Type: ROUTE-LOOKUP

Subtype: Resolve Egress Interface

Result: ALLOW

Config:

Additional Information:

found next-hop 96.90.44.142 using egress ifc  FTD-OUTSIDE

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group CSM_FW_ACL_ global

access-list CSM_FW_ACL_ advanced permit ip ifc FTD-OUTSIDE any ifc FTD-OUTSIDE any rule-id 268434443

access-list CSM_FW_ACL_ remark rule-id 268434443: ACCESS POLICY: IR Access Policy - Mandatory

access-list CSM_FW_ACL_ remark rule-id 268434443: L7 RULE: Allow S2S VPN Inet

Additional Information:

This packet will be sent to snort for additional processing where a verdict will be reached

Forward Flow based lookup yields rule:

in  id=0x2aaad2f76820, priority=12, domain=permit, deny=false

hits=15, user_data=0x2aaac7b22e80, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, ifc=FTD-OUTSIDE

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, ifc=FTD-OUTSIDE, vlan=0, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 3

Type: CONN-SETTINGS

Subtype:

Result: ALLOW

Config:

class-map class-default

match any

policy-map global_policy

class class-default

  set connection advanced-options UM_STATIC_TCP_MAP

service-policy global_policy global

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x2aaad2db36e0, priority=7, domain=conn-set, deny=false

hits=265644, user_data=0x2aaad2daea90, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=FTD-OUTSIDE, output_ifc=any

Phase: 4

Type: NAT

Subtype:

Result: ALLOW

Config:

object network ASA5515-Internal-Net

nat (FTD-OUTSIDE,FTD-OUTSIDE) dynamic interface

Additional Information:

Dynamic translate 192.168.123.111/65478 to 96.90.44.140/65478

Forward Flow based lookup yields rule:

in  id=0x2aaacf5bdb30, priority=6, domain=nat, deny=false

hits=0, user_data=0x2aaad2f1c2c0, cs_id=0x0, flags=0x0, protocol=0

src ip/id=192.168.123.0, mask=255.255.255.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=FTD-OUTSIDE, output_ifc=FTD-OUTSIDE

Phase: 5

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x2aaad1b27830, priority=0, domain=nat-per-session, deny=false

hits=175235, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x2aaad26775e0, priority=0, domain=inspect-ip-options, deny=true

hits=364669, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=FTD-OUTSIDE, output_ifc=any

Phase: 7

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x2aaad2e4ab50, priority=13, domain=ipsec-tunnel-flow, deny=true

hits=9368, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=FTD-OUTSIDE, output_ifc=any

Phase: 8

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0x2aaad1b27830, priority=0, domain=nat-per-session, deny=false

hits=175237, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=any, output_ifc=any

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0x2aaad26775e0, priority=0, domain=inspect-ip-options, deny=true

hits=364671, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0

input_ifc=FTD-OUTSIDE, output_ifc=any

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 365769, packet dispatched to next module

Module information for forward flow ...

snp_fp_inspect_ip_options

snp_fp_tcp_normalizer

snp_fp_snort

snp_fp_translate

snp_fp_tcp_normalizer

snp_fp_adjacency

snp_fp_fragment

snp_fp_tracer_drop

snp_ifc_stat

Module information for reverse flow ...

snp_fp_inspect_ip_options

snp_fp_tcp_normalizer

snp_fp_translate

snp_fp_snort

snp_fp_tcp_normalizer

snp_fp_adjacency

snp_fp_fragment

snp_fp_tracer_drop

snp_ifc_stat

Phase: 11

Type: EXTERNAL-INSPECT

Subtype:

Result: ALLOW

Config:

Additional Information:

Application: 'SNORT Inspect'

Phase: 12

Type: SNORT

Subtype:

Result: DROP

Config:

Additional Information:

Snort Trace:

Packet: TCP, SYN, seq 993247618

AppID: service unknown (0), application unknown (0)

Firewall: starting rule matching, zone 5 -> 5, geo 0 -> 0, vlan 0, sgt 65535, username 'No Authentication Required', , icmpType 0, icmpCode 0

Firewall: block rule,  'Default Action' , drop

Snort: processed decoder alerts or actions queue, drop

NAP id 2, IPS id 0, Verdict BLACKLIST, Blocked by Firewall

Snort Verdict: (black-list) black list this flow

Result:

input-interface: FTD-OUTSIDE

input-status: up

input-line-status: up

output-interface: FTD-OUTSIDE

output-status: up

output-line-status: up

Action: drop

Drop-reason: (firewall) Blocked or blacklisted by the firewall preprocessor

For the life of me, I cannot figure out why, phase 12 and 13 are blocking the traffic.  I tried searching for more information, but to no avail. 

We are running into this issue at a client and this is why I am trying to find the answer.  We had two TAC engineers on with the client earlier this week.  They both confirmed that this should work in FTD, but couldn't find the solution. 

If you want to see more of the config, let me know and I will post it up.

[bkastor]

Hi deyster94,

Can you change your Default Action to Allow? Just to test.. ?

It looks like Phase 12 is saying that the traffic is in a BLACKLIST.

Either that, or Trust the traffic, so it doesn't go through the IPS portion of the Policy. When I was doing my test the other day, my Default Action was set to Allow.

If you want to test that.. make sure it works, then maybe work backwards to what is blocking it...

[rangertdc]

Hey, I'm not sure if you found a solution to this, but I had a similar issue with hairpinned traffic on a 2110 appliance running the thread defense image.  The workaround from TAC that solved the issue for me was to remove the zone definitions on the access rule and just use source and destination network.

This was the bug they listed as causing the issue.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg08988