Site-To-Site VPN - Showing Allowed Ports

[sadik.bash]

Hello,

I have HQ(Site A) ASA5505 setup with two VPN Tunnels establised to remote sites(Site B and Site C). All is working just fine. I am able to ping devices at each subnet(From Site A to Site B and Site C and vice versa) successfully; however, devices cann't comunicate to a server at HQ (Site A) and I wanted to make sure that the ports are open through the Tunnels. How do I accomplish that?

Much appreciated!

Best, ~sK

[Jouni Forss · Accepted solution]

Hi,

There are many things that decide what traffic is forwarded to L2L VPN connections and what is allowed through the actual firewalls.

First of all you naturally want to confirm that the host that need to communicate are truly configured on the L2L VPN configurations. In the ACL that defines the traffic.

If that mentioned ACL is fine then you probably want to have a look at the NAT configurations are ok. Are you using NAT0 for all the traffic on all of these L2L VPN connections?

Then you naturally want to confirm that the host iniating the connections allowed to form the connection through the "inside" interface ACL on the local ASA.

Then theres a "sysopt connection permit-vpn". This configuration command controls the setting if connections coming through VPN connections are allowed to bypass the "outside" interface ACL. The default setting for ASA is that all connections entering from VPN connection are automatically bypassing the "outside" interface ACL (or rather the ACL of the interface where the VPN is terminated on the ASA, though its 99% of the time "outside")

To check the status of the above mentioned setting issue the command "show run sysopt". If you dont see anything related to the "vpn" in the output then you will know that the setting is at its default and therefore isnt blocking the connections. If there is a "no sysopt connection permit-vpn" then that means that you will need to allow all the required traffic though the "outside" interface ACL.

To test if certain traffic correctly gets forwarded to the L2L VPN at its LOCAL ASA then you can use the "packet-tracer" command.

Format would be

• Presuming traffic is initiated from behind interface "inside"

packet-tracer input inside tcp

This will print a long'ish message on the CLI that will tell all the check that are done for the traffic you are attempting to simulate. It will also inform your of the NAT and ACL rules the traffic is matching. It will also mention if the traffic is forwarded to a VPN connection.

Natutally firewall logs are a great tool to determine where the traffic stops (Checking from all the ASAs related to the connection attempt). The ASDM GUI (monitor section) is great for this purpose.

Also if you want to go even deeper you can capture packets on the ASA firewall. Though since in this case we are talking about VPN/encrypted traffic you can only take the capture on the "inside" interface as traffic entering/leaving the interface isnt encrypted.

I dont think the ASA provides any tool to tell you what traffic is allowed through the L2L VPN connection. You will have to use the combination of the above things to determine that. Naturally you might be able to run some program on a host behind the ASA to scan open ports.

Hopefully some of the above information will help you figure out whats wrong.

Naturally ask if you need more information about something I mentioned above. If you take "packet-tracer" output from some of the ASAs you can share the output here for us to look through.

EDIT: Typos

EDIT2: Even more strange typos. Think I'm too tired.

- Jouni

[sadik.bash]

Thanks for the prompt response and very usefual info, Jouni!

The answer is "Yes" to the first 3 paragraph above.

I issued the sh run sysopt and the output was clear.

Here are the ACL and NAT statemenst:

access-list BurToMsy extended permit ip 10.20.0.0 255.255.255.0 10.40.1.0 255.255.255.0

access-list nonat extended permit ip 10.20.0.0 255.255.255.0 10.40.1.0 255.255.255.0

access-list nonat extended permit ip 10.20.0.0 255.255.255.0 10.30.1.0 255.255.255.0

access-list BurToRdu extended permit ip 10.20.0.0 255.255.255.0 10.30.1.0 255.255.255.0

Here is the results of the packet-tracer:

CV-ASA-01# packet-tracer input inside tcp 10.20.0.30 9001 10.30.1.103 9001

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT-EXEMPT

Subtype:

Result: ALLOW

Config:

  match ip inside 10.20.0.0 255.255.255.0 outside 10.30.1.0 255.255.255.0

    NAT exempt

    translate_hits = 158, untranslate_hits = 69504

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

static (inside,outside) 70.15.23.55 10.20.0.30 netmask 255.255.255.255

  match ip inside host 10.20.0.30 outside any

    static translation to 70.15.23.55

    translate_hits = 49836, untranslate_hits = 270812

Additional Information:

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,outside) 70.15.23.55 10.20.0.30 netmask 255.255.255.255

  match ip inside host 10.20.0.30 outside any

    static translation to 70.15.23.55

    translate_hits = 49836, untranslate_hits = 270812

Additional Information:

Phase: 7

Type: VPN

Subtype: encrypt

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

[sadik.bash]

Public IP addresses appearing in the packer-tracer output aren't the actual IP address!

Best, ~sK

[sadik.bash]

How do I find out if the inside local IP address at Site B or Site C was natted or not across the VPN tunnel? We have a vendor who reported that at Site A, where the ASA5505 is located, the server is receiving the inside global IP, router's public IP address and not the inside local IP address of the devices. I have checked the NAT'ng statements and here is how I have them setup:

Site A(HQ- ASA5505):

access-list nonat extended permit ip 10.20.0.0 255.255.255.0 10.40.1.0 255.255.255.0
access-list nonat extended permit ip 10.20.0.0 255.255.255.0 10.30.1.0 255.255.255.0

global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0

Site B:

interface FastEthernet0

no ip address

!

!

interface FastEthernet4

ip address dhcp

ip nat outside

ip virtual-reassembly in

duplex auto

speed auto

crypto map OUTSIDE_MAP

!

interface Vlan1

ip address 10.40.1.254 255.255.255.0

ip nat inside

ip virtual-reassembly in

!

ip nat source route-map nonat interface FastEthernet0 overload

ip nat inside source list inside-nat-pool interface FastEthernet4 overload

ip nat inside source static 10.40.1.0 0.0.0.255

!

ip access-list extended inside-nat-pool

deny   ip 10.40.1.0 0.0.0.255 10.20.0.0 0.0.0.255

permit ip 10.40.1.0 0.0.0.255 any

!

access-list 110 deny   ip 10.40.1.0 0.0.0.255 10.20.0.0 0.0.0.255

access-list 110 permit ip 10.40.1.0 0.0.0.255 any

access-list 190 permit ip 10.40.1.0 0.0.0.255 10.20.0.0 0.0.0.255

!

route-map nonat permit 10

match ip address 110

!

Site C:

interface FastEthernet0
no ip address
!
interface FastEthernet4
ip address a.b.c.d 255.255.255.252
ip nat outside
ip virtual-reassembly in
duplex full
speed auto
crypto map OUTSIDE_MAP
!
interface Vlan1
ip address 10.30.1.254 255.255.255.0
ip nat inside
ip virtual-reassembly in
!
ip nat inside source list inside-nat-pool interface FastEthernet4 overload
ip nat inside source list nonat interface FastEthernet0 overload
ip nat inside source static 10.30.1.0 0.0.0.255
ip route 0.0.0.0 0.0.0.0 a.b.c.d
!
ip access-list extended inside-nat-pool
deny   ip 10.30.1.0 0.0.0.255 10.20.0.0 0.0.0.255
permit ip 10.30.1.0 0.0.0.255 any
!
access-list 190 permit ip 10.30.1.0 0.0.0.255 10.20.0.0 0.0.0.255

Much appreciated.

Best, ~sK