Direct specific ports down a L2L VPN

[jeffreymertz]

I have a client that is trying to use an ISP hosted web filtering and content management gateway, the ISP wants to use and L2L ISPEC VPN from the site to their gateway to control traffic. We got the tunnel up today with a test ACL for test client side devices to go down the tunnel, but they are blocking all traffic that isn't being scanned. The problem is they are on an ASA 5510 with 8.2.2. You cannot add tcp ports into the nonat ACL, it errors out when you try to apply the nat (inside) 0 access-list nonat statement. We can define ports to go down the VPN in the interesting traffic ACL with out issue, but there is no way to send just the web ports down the VPN, and allow other ports out the regular overflow interface NAT. I have been looking into 8.4 and seeing if it allows a policy NAT (twice NAT for the VPNs) to define a port on an IP range (IE: nat (inside,outside) source static WEBINSPECT WEBINSPECT destination static any any ) but define that as web ports only.

I don't have a test ASA to use, but i'm guessing that l2l vpn will be by IP only and I can't define a port to tunnel.

Anyway, this is an odd one but ideas are welcome. I don't think it is easily possible, but I thought I would see if anyone has run into this before.

[Jouni Forss · Accepted solution]

Hi,

Well to give you a simple example where we can use the Twice NAT / Manual NAT to manipulate the traffic forwarding

For example a sample configuration I just did on my ASA 8.4(5)

The following configuration will

• Define "object" that contains the source network for the NAT
• Define "object" that contains the service for the NAT
• Define the actual NAT

The actual NAT will do so that any connection coming from the network under the "object network WIRELESS" to destination port TCP/80 will be forwarded through "WAN" interface without NAT

Naturally this the next step with L2L VPN is that the network under "object network WIRELESS" would match the L2L VPN ACL. But that seemed straight forward for you already

object network WIRELESS

subnet 10.0.255.0 255.255.255.0

object service WWW

service tcp destination eq www

nat (WLAN,WAN) source static WIRELESS WIRELESS service WWW WWW

The following configuration will

• Define "object-group" which defines the source network(s) for the Default PAT rule for Internet traffic
• Define "object" for the PAT address (could just use "interface" instead of the "object")
• Define the actual NAT

The actual NAT configuration will just do a Default PAT rule for the WIRELESS network. The key thing to notice here is that we use "after-auto" parameter. This basically inserts the NAT rule at the very bottom priority of the ASA.

object-group network WIRELESS-NETWORK

network-object 10.0.255.0 255.255.255.0

object network PAT-1.1.1.1

host 1.1.1.1

nat (WLAN,WAN) after-auto source dynamic WIRELESS-NETWORK PAT-1.1.1.1

Now we can use "packet-tracer" command to confirm that the NAT is operating as expected.

TESTING WWW -TRAFFIC

ASA(config)# packet-tracer input WLAN tcp 10.0.255.100 12355 1.2.3.4 80

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (WLAN,WAN) source static WIRELESS WIRELESS service WWW WWW

Additional Information:

NAT divert to egress interface WAN

Untranslate 1.2.3.4/80 to 1.2.3.4/80

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (WLAN,WAN) source static WIRELESS WIRELESS service WWW WWW

Additional Information:

Static translate 10.0.255.100/12355 to 10.0.255.100/12355

Phase: 4

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (WLAN,WAN) source static WIRELESS WIRELESS service WWW WWW

Additional Information:

Phase: 6

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: WLAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: allow

TESTING FTP -TRAFFIC

ASA(config)# packet-tracer input WLAN tcp 10.0.255.100 12355 1.2.3.4 21

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         WAN

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: INSPECT

Subtype: inspect-ftp

Result: ALLOW

Config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

  inspect ftp

service-policy global_policy global

Additional Information:

Phase: 4

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (WLAN,WAN) after-auto source dynamic WIRELESS-NETWORK PAT-1.1.1.1

Additional Information:

Dynamic translate 10.0.255.100/12355 to 1.1.1.1/12355

Phase: 5

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (WLAN,WAN) after-auto source dynamic WIRELESS-NETWORK PAT-1.1.1.1

Additional Information:

Phase: 7

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: WLAN

input-status: up

input-line-status: up

output-interface: WAN

output-status: up

output-line-status: up

Action: allow

As you can see the TCP/80 traffic matches the other rule. And the FTP used as an example matches the Default PAT rule as expected.

If you want to read a bit more about the new NAT format 8.3+ you can check a document I created

https://supportforums.cisco.com/docs/DOC-31116

Hopefully this helps Please mark the question as answered if it did or rate answer.

Naturally ask more if needed

- Jouni

[jeffreymertz]

So the only way is to nat before the VPN. I didn't want to have to do that, as then we can't define source traffic per the radius auth the ISP is using to match IP traffic to user. If we nat then pump down the tunnel, all the traffic is from a single source IP that doesn't match an IP in the auth database for the ISP gateway.

I'll give it a 4 rating as it is an pretty good guide to nat before manipulating outside traffic, but i alreay know how to do that.

I know how to use nat in 8.4, I just don't have a test 5510, only a few basic 5505s 10 users in stock for some smaller clients.

what i need to do, is define traffic to 80/443 from a subset of the lan subnets, pump that down the l2l VPN, and pump the rest out the overflow. Not split the nat out different interfaces, but split the policy nat for the L2L VPN (or nonat on 8.2 as they don't have smartnet for upgrade)

I'd prefer they just get a barracuda or another pass through device, but they believe sales people before their own IT consulting company apparently.

[Jouni Forss]

Hi,

The example NAT configuration for WWW specifically keeps the source address intact. The only NAT configuration that NATs to a single IP address is just an example to illustrate that the other type of connections still hit the Default PAT rule. Only the network defined with WIRELESS object with destination TCP/80 gets NATed to itself (or rather not NATed at all) so that it potentially hits the L2L VPN with its real source IP address.

And you can easily modify and add similiar NAT configurations to choose which internal networks WWW traffic is NATed this way (or as stated NOT NATed) and keep rest of the networks using the actual Internet connection rather than the L2L VPN.

- Jouni

[jeffreymertz]

I see that it keeps the IP when it NATs to the port 80. How would I get that down a VPN.

Normal VPN nat (as below) will ensure defined interesting traffic doesn't global nat and tries to go down the defined VPN tunnel.

8.2:  access-list nonat extended permit ip

        nat (inside) 0 access-list nonat

8.3

nat (inside,outside) source static destination static

If I'm starting to understand it correctly, to use your example of port based policy mapping, I would nat my subnet to itself only for www (as it is going to be a destination of "any" as I it is outbound) and my VPN is still defined as that subnet with that port. so:

object network LAN-WEBFILTER

subnet 10.0.3.0 255.255.255.0

object network LAN-NOFILTER

subnet 10.0.3.0 255.255.255.0

object-group service WEBPORTS

service-object tcp eq 80

service-object tcp eq 443

object network any-NOFILTER

host

nat (inside,outside) source static LAN-WEBFILTER LAN-WEBFILTER service WEBPORTS WEBPORTS

nat (inside,outside) after-auto source dynamic wireless-network any-NOFILTER

so, now that traffic is hitting the outside interface as the source IP, instead of the globally natted "overflow" ip (to borrow a term from the router side of things), the VPN interesting traffic ACL should regocnize the IPs.

okay, I was reading on my phone before I didn't quite get it, thanks so much. I think I understand what you were going for, the secondary definition of the after-auto command was what I was missing before, I didn't know you could do that.

I'll see if they are up for renewing the smartnet so we can upgrade to 8.4.

[Jouni Forss]

Hi,

The basic idea in the above new NAT format configuration was the following

• The LAN network will not be NATed when the connection coming to the ASA is heading anywhere behind the "outside" interface and with the destination service TCP/80
• Provided that the L2L VPN ACL defines the local source as the local LAN network the TCP/80 traffic should match the L2L VPN interesting traffic after the NAT operations have been gone through by the ASA and it reaches the VPN phase.
• Naturally any other destination port traffic will not match this NAT rule and therefore probably hits another default NAT/PAT rule and therefore also NOT hit the L2L VPN connection and head out normally out the "outside" interface.
• Naturally if you need the same behaviour for multiple services you will configure a similiar NAT rule for all of them.

I was wondering if we could do the same with the 8.2 software (or below)

I was thinking of a NAT configuration like this

access-list L2L-VPN-POLICYNAT permit tcp 10.0.255.0 255.255.255.0 any eq www

access-list L2L-VPN-POLICYNAT permit tcp 10.0.255.0 255.255.255.0 any eq https

static (inside,outside) 10.0.255.0 access-list L2L-VPN-POLICYNAT

This to my understanding should do pretty much the same as the new software format. There are naturally differences between the software levels which make them a bit different to handle. The new software gives a lot more options to modify the existing NAT rule order while the old isnt that flexible.

- Jouni

[jeffreymertz]

I'm not even going to try to mess with it in 8.2 or older. I've done nat -> vpn on it before for vendor VPNs requiring specific source IPs. not fun, much easier on 8.4.

I'll take your advice and do seperate nats for each service instead of a service group. Thanks again, make sense now that I had some time to sit down and obsorb it.

We are getting a quote to a client for smartnet (they declied the last one we sent during their renewal )

[Jouni Forss]

Ok,

I would be a bit hesitant myself playing around with 8.2 NAT

I think actually that the ASA 8.3+ doesnt accept "object-group service" in the NAT configurations. And as "object service" can only contain one entry I guess it makes for multiple NAT configuration lines/objects depending on the needs.

- Jouni

[jeffreymertz]

it's supposed to, but we can't get it to work for inbound PAT, so we just have 30 object lines.

object network EXCH-WEB

object network EXCH-SMTP

etc..

thanks again, I knew I could probably nat to external IP per port, then send down VPN (I've done that a few times already), but I would lose source IP for radius auth. at the gateway. I didn't think about doing a service policy NAT before the VPN with 8.3+. Makes all the sense in the world to me now.

Jeff