unable to access Internal HTTPS through VPN conn

[dmooregfb]

Anytime I have internal websites with HTTPS connections that do not have valid certificates, our VPN users are unable to make a connection. The wireshark trace shows acknowlegement number = broken TCP.  I have run Packet Tracer and it shows a problem on my DMZ???? not sure why as the traffic flow is inside to inside interface. I am at a total lost as to why...

+++++++++++++++++++++++++++++++

ASA 5520 with 8.4(1) code

VPN Addressing = 172.25.17.0/24

HTTP Server = 172.18.2.13 (port 8443)

Can ping by IP Address or by server name

Can access site internally after responding to the Certificate Warning

++++++++++++++++++++++++++++

Any help is greatly appreciated!

Dave

[Jouni Forss]

Hi,

Are the VPN users connecting to the ASA or some other device?

Also why would the traffic be "inside" to "inside"? If the connections are coming to the ASA then it would usually be "outside" to "inside" since the VPN Clients would be located behind the "outside" interface from ASAs perspective.

If the situation was that the VPN was on another device than this ASA and both of the networks were behind the "inside" interface then the traffic should not even go through the ASA.

Maybe you could share the "packet-tracer" output from the CLI of the ASA so we could see what you mean.

- Jouni

[Jouni Forss]

Also,

Now that I look at it, You mention above that the port on the server is TCP/8443 but the port in the capture is TCP/443 ?

- Jouni

[dmooregfb]

Jouni, let me clear up a few here:

• VPN users inbound on outside2 to inside interfaces (misquote)
• This is the URL when converted (after accepting the non-certificate message); so this is somewhat of confusion for the TCP/8443 and TCP/443
•      https://172.18.2.13:8443/appadmin/main
• adding a .png of the packet trace.

Dave

[Jouni Forss]

Hi,

The UN-NAT is the most essential part of that output and its the only thing that is not showing

But I would have to guess that the destination IP address of the above packet matches a NAT configurations and this NAT configuration then overrides the actual interface to which the packet should be forwarded to.

- Jouni

[dmooregfb]

Here is the expanded version

[Jouni Forss · Accepted solution]

Hi,

The NAT configuration mentioned in your screencapture is the configuration that causes all traffic from the VPN users to be diverted to the "HomeOffice" interface because "any any" is configured

You would either have to make the above rule more specific by removing the "any any" and adding the actual networks

OR

You could add a new rule BEFORE the above mentioned NAT configurations

I am not sure what the real local interface "nameif" is (the one where the server IP is actually located) but you would need this kind of configurations

object network SERVER

host 172.18.2.13

object network VPN-POOL

subnet 172.25.17.0 255.255.255.0

nat (serverint,outside2) 1 source static SERVER SERVER destination static VPN-POOL VPN-POOL

The above rule should match the traffic from the VPN-POOL to the SERVER. The number "1" seen in the CLI format configurations means that it would be added to the top of the rules. The "serverint" is meant to mean the actual name of the interface where the server is located as I presume that its not located behind the "HomeOffice"

- Jouni

[dmooregfb]

Jouni Forss , this worked out correctly. I removed all NAT parms and reconfigured. It appeared as there was a twice NAT going on.

Thanks for your time,

Dave