topic unable to access Internal HTTPS through VPN conn in Network Security

unable to access Internal HTTPS through VPN conn

dmooregfb — Tue, 12 Mar 2019 03:52:51 GMT

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

unable to access Internal HTTPS through VPN conn

Jouni Forss — Mon, 03 Mar 2014 13:54:09 GMT

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

unable to access Internal HTTPS through VPN conn

Jouni Forss — Mon, 03 Mar 2014 13:56:52 GMT

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

unable to access Internal HTTPS through VPN conn

dmooregfb — Mon, 03 Mar 2014 14:08:04 GMT

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

unable to access Internal HTTPS through VPN conn

Jouni Forss — Mon, 03 Mar 2014 14:12:39 GMT

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

unable to access Internal HTTPS through VPN conn

dmooregfb — Mon, 03 Mar 2014 14:16:45 GMT

Here is the expanded version

Re: unable to access Internal HTTPS through VPN conn

Jouni Forss — Tue, 04 Mar 2014 12:32:39 GMT

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

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

Jouni Forss , this worked out

dmooregfb — Tue, 11 Mar 2014 16:24:34 GMT

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