Using a Public IP Address as the Source on a L2L VPN Tunnel

[Keith Partin]

I have a client with whom I am setting up a site-to-site VPN connection.  I have done this before but always with private IPs going across the tunnel.  This customer insists that all traffic appear to be from a single public address, with his servers as the destination.  I have a 5510 with current software.

My public IP space (anonymized):

111.111.111.192/27

111.111.111.193 is my gateway and all VPNs terminate on the outside interface, 111.111.111.194.

The client uses public IPs internally, so the servers we are trying to reach are on 222.222.222.0/24 (but accessible only over the tunnel).

Let’s say my internal subnet for this project is 10.140.0.0/23.

When my guys access the client’s servers over the tunnel, from their perspective it is a call from (for example) 10.140.0.10 to 222.222.222.15.  What the client wants to see over the tunnel in this case is traffic from 111.111.111.210 (one of my public IPs) to 222.222.222.10.

The basic problems are getting the 111.111.111.210 address to be the source on the VPN tunnel, and getting it to use the tunnel at all.

I have googled this to death and found a lot of similar cases, but nothing that seemed to exactly match this.  I tried a million NAT rules, including Twice NAT, but can’t quite get it right.

All help very much appreciated.

[pjain2]

here is what you would need to do:

object network obj-10.140.0.0/23

subnet 10.140.0.0 255.255.254.0

nat (inside) dynamic 111.111.111.210

crypto acl:

access-list cryptoacl match ip host 111.111.111.210 222.222.222.0 255.255.255.0

when the trafic from your internal subnet 10.140.0.0/23 comes on the ASA's inside interface, it will be patted to ip 111.111.111.210 and then hit the outside interface crypto and then go out through the tunnel; you do not need any nat exemption for this traffic,

the cryptoacl on the remote end should be the exact opposite of the crypto acl defined above.

[Keith Partin]

Thanks.  I guess I failed to include two critical points:

1.  The devices on the inside subnet (10.140.0.0) need to send regular traffic and tunnel traffic

2.  So this is essentially a destination NAT, wherein the NAT rule matches when the destination matches the client's subnet.

The NAT rule below seems to handle this nicely --- any traffic on the local subnet with a destination of the client's subnet has it's source NAT'd to the public "from" address the client wants to see, and the destination IP is left alone.

nat (inside,outside) source dynamic [local-subnet] 111.111.111.210 destination static [222.222.222.0 subnet] [222.222.222.0 subnet]

Packet-tracer shows the NAT'ing to be working as expected, but fails on the VPN encrypt phase:

Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7fffe3720a70, priority=70, domain=encrypt, deny=false
        hits=19, user_data=0x0, cs_id=0x7fffe364eee0, reverse, flags=0x0, protocol=6
        src ip/id=111.111.111.210, mask=255.255.255.255, port=0, tag=any
        dst ip/id=222.222.222.0, mask=255.255.255.0, port=0, tag=any
        dport range<0> : xxxx-yyyy, dscp=0x0
        input_ifc=any, output_ifc=outside

Sending any traffic to the destination subnet brings up the tunnel, but no traffic passes.

Thanks again for your help.

[Richard Bradfield]

Keith,

I can see your problem. I think the only way round this is to have another Internet connection

then have a vpn router( I don't know whether you can have more than one context on a 5510) from your current outside network to the 222.222.222.0 /24 thru the new Internet connection.

Good luck

Richard.