topic Start a packet capture and in Network Security

Can't ping or connect to port 443 on external interface

andrewgori — Tue, 26 Mar 2019 01:00:24 GMT

I need a bit of a reality check here. I have a 5515x with two outbound connections. One interface is connected to an ISP. The other is connected to a stub network for testing. From inside networks, I can ping through, browse the web, etc using policy based routing to direct flow via the correct interface. However, I cannot connect to the firewall from outside using either icmp or port 443. I have an explicit rule on the interface to allow icmp and the interface is enabled for Anyconnect. Packet traces indicate that both icmp connections to port 443 should work. If I plug a laptop in outside the firewall, I can ping and telnet to port 443. The ISP claims it is not blocking ports or traffic. Regardless, I cannot connect. What could I be missing?

Thanks.

Hi

Francesco Molino — Thu, 08 Jun 2017 00:07:24 GMT

Can you share your config on text file (don't forget to remove all confidential stuff)?

Have you ran packet-tracer command? Can you share the output please?

The command should be :

Packet-tracer input outside icmp 8.8.8.8 8 0 ip-outside-asa

Saying what the cause of the issue is without more information is a bit difficult.

Thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question

It could be routing.

Marvin Rhoads — Thu, 08 Jun 2017 08:19:31 GMT

It could be routing.

Also note that an "outside access-list in" ACL controls traffic THROUGH the ASA - not traffic TO the ASA.

I think routing is OK since

andrewgori — Thu, 08 Jun 2017 15:29:06 GMT

I think routing is OK since internal clients can access outside web pages, etc.

Start a packet capture and

Marvin Rhoads — Thu, 08 Jun 2017 15:41:23 GMT

Start a packet capture and try to connect. Share what you find here or with your ISP. That should eliminate conjecture.

Thanks to both of you for the

andrewgori — Thu, 08 Jun 2017 16:41:43 GMT

Thanks to both of you for the input.

It looks like it may be a routing issue of sorts after all. If I'm reading the output correctly, it's pushing the return packets out the external-ISP1 interface rather than external-ISP2 that the ICMP packets originally came in on. (default route is via External-ISP1) How do I make the replies go out the correct interface? Do I need another Policy Based Route? I'm trying to work through the flow logic.

5515x# packet-tracer input external-ISP2 icmp 8.8.8.8 0 0 10.90.7.12

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.211.84.113 using egress ifc  external-ISP1

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group External-ISP2_access_in in interface External-Integra
access-list External-ISP2_access_in extended permit icmp any any
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 2228722, packet dispatched to next module

Result:
input-interface: External-ISP2
input-status: up
input-line-status: up
output-interface: external-ISP1
output-status: up
output-line-status: up
Action: allow

PBR is not very useful in

Marvin Rhoads — Thu, 08 Jun 2017 16:50:38 GMT

PBR is not very useful in most uses cases for incoming Internet traffic. If you know the client source address sure you can use it. But this is not normally the case in most situations outside the lab or testbed.

Thank you for the input; that

andrewgori — Thu, 08 Jun 2017 17:11:16 GMT

Thank you for the input; that makes sense. Is there a viable way to host AnyConnect via an interface that is not used as the default route? We're not running any routing protocols, just static routes for internal traffic and next-hop to the ISP's so there is no dynamic routing done by our hardware. At this point, I'm thinking I may need to re-evaluate my plan.

SSL VPN (Anyconnect) is

Marvin Rhoads — Thu, 08 Jun 2017 17:15:35 GMT

SSL VPN (Anyconnect) is almost always served up on the default route interface.

You really cannot effectively do it with dual ISPs except in cases where one is essentially standby and you have an ip sla monitor to swing the default route to it when the primary fails.

Why do you not want to use the current primary ISP connection for SSL VPN?

I'm not vested in the idea

andrewgori — Thu, 08 Jun 2017 17:24:48 GMT

I'm not vested in the idea of serving VPN via the second interface. I'm just trying to relieve some of the load off of the default route interface. I have a couple of other options for separating traffic and will go down that route instead. Simply moving a large enough portion of the outbound desktop/wifi traffic should suffice. With my newly acquired knowledge, seems like a simpler approach. 🙂

Thanks again. I appreciate the help.

You're welcome.

Marvin Rhoads — Thu, 08 Jun 2017 17:29:12 GMT

You're welcome.

Please let me know if you have any other questions.