- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-24-2020 10:19 AM - edited 11-24-2020 10:20 AM
Hi all, I'll preface this as I'm the sole networking guy at my job and I'm still green. Apologies for any dumb questions, I've tried to read the manual for relevant info and used my google-fu to no avail.
I'm using a PA-3020 on firmware 8.0.6.
I've been asked to integrate a new Cisco ASA for a financial system that allows a tunnel between my site, and their servers to load the webpage client for the software.
I've setup a DMZ for the ASA, and confirmed with the other party that their tunnel is up and able to communicate. So no issues on the DMZ side.
I was told to institute static routes to allow hosts to traverse via the ASA over the tunnel. The ASA has two interfaces configured, one for WAN, which is in our DMZ on the IP 10.10.254.1.
The other ASA interface is meant for our internal LAN, and the interface is configured for 10.10.3.253.
I'm not 100% sure but I have a feeling my static route is not functioning as intended. Setting a route via windows to the ASA's internal interface (10.10.3.253) will allow me to traverse the tunnel to the needed webpage. Similarly, using another L3 device (velocloud) with static routes set to the ASA's internal IP (10.10.3.253) also allows me traverse the tunnel to the web page.
Looking at the CLI, I confirmed the routing table and tested the route and it seems to forward it to ASA's LAN interface at 10.10.3.253. I've checked my firewall security policies, and explicitly allowed traffic on my 10.10.3.0/24 segment to and from the ASA's interface at 10.10.3.253. Is there anything I've missed, or misconfigured?
A tracert via windows reveals the following:
C:\Users\sferguson>tracert -d 208.64.237.43 Tracing route to 208.64.237.43 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.10.3.111 2 22 ms 22 ms 23 ms 208.*.237.43
Which is indicitivate to me for traversal over a tunnel
My tests:
*@PA-3020> show routing fib
--------------------------------------------------------------------------------
virtual-router name: Primary VR
interfaces:
ethernet1/3 ethernet1/4 ethernet1/5 ethernet1/12
tunnel tunnel.99 tunnel.100 tunnel.101
route table:
flags: u - up, h - host, g - gateway, e - ecmp, * - preferred path
id destination nexthop flags interface mtu
--------------------------------------------------------------------------------
91 0.0.0.0/0 72.*.182.1 ug ethernet1/3 1500
7 10.10.1.0/24 0.0.0.0 u tunnel.99 1500
71 10.10.2.0/24 0.0.0.0 u tunnel.101 1500
30 10.10.3.0/24 0.0.0.0 u ethernet1/4 1500
29 10.10.3.111/32 0.0.0.0 uh ethernet1/4 1500
135 10.10.254.0/24 0.0.0.0 u ethernet1/5 1500
134 10.10.254.254/32 0.0.0.0 uh ethernet1/5 1500
12 10.99.99.0/24 10.99.99.0 ug tunnel 1500
76 40.*.92.104/29 0.0.0.0 u ethernet1/12 1500
75 40.*.92.106/32 0.0.0.0 uh ethernet1/12 1500
88 72.*.182.0/29 0.0.0.0 u ethernet1/3 1500
87 72.*.182.2/32 0.0.0.0 uh ethernet1/3 1500
147 207.*.128.0/21 10.10.3.253 ug ethernet1/4 1500
148 207.*.139.0/25 10.10.3.253 ug ethernet1/4 1500
149 208.*.237.43/32 10.10.3.253 ug ethernet1/4 1500
150 208.*.237.44/32 10.10.3.253 ug ethernet1/4 1500
--------------------------------------------------------------------------------
*@PA-3020> show routing route
flags: A:active, ?:loose, C:connect, H:host, S:static, ~:internal, R:rip, O:ospf, B:bgp,
Oi:ospf intra-area, Oo:ospf inter-area, O1:ospf ext-type-1, O2:ospf ext-type-2, E:ecmp, M:multicast
VIRTUAL ROUTER: Primary VR (id 1)
==========
destination nexthop metric flags age interface next-AS
0.0.0.0/0 40.*.92.105 200 S ethernet1/12
0.0.0.0/0 72.*.182.1 10 A S ethernet1/3
10.10.1.0/24 0.0.0.0 10 A S tunnel.99
10.10.2.0/24 0.0.0.0 10 A S tunnel.101
10.10.3.0/24 10.10.3.111 0 A C ethernet1/4
10.10.3.111/32 0.0.0.0 0 A H
10.10.254.0/24 10.10.254.254 0 A C ethernet1/5
10.10.254.254/32 0.0.0.0 0 A H
10.99.99.0/24 10.99.99.0 10 A S tunnel
40.*.92.104/29 40.*.92.106 0 A C ethernet1/12
40.*.92.106/32 0.0.0.0 0 A H
72.*.182.0/29 72.*.182.2 0 A C ethernet1/3
72.*.182.2/32 0.0.0.0 0 A H
207.2*.128.0/21 10.10.3.253 1 A S ethernet1/4
207.2*.139.0/25 10.10.3.253 1 A S ethernet1/4
208.*.237.43/32 10.10.3.253 1 A S ethernet1/4
208.*.237.44/32 10.10.3.253 1 A S ethernet1/4
total routes shown: 17
*@PA-3020> test routing fib-lookup virtual-router "Primary VR" ip 208.*.237.44
--------------------------------------------------------------------------------
runtime route lookup
--------------------------------------------------------------------------------
virtual-router: Primary VR
destination: 208.*.237.44
result:
via 10.10.3.253 interface ethernet1/4, source 10.10.3.111, metric 1
--------------------------------------------------------------------------------
*@PA-3020> test security-policy-match from "LAN Zone" to "LAN Zone" source 10.10.3.24 destination 10.10.3.253 destination-port 443 application web-browsing protocol 6
"*-1; index: 14" {
from "LAN Zone";
source any;
source-region none;
to "LAN Zone";
destination 10.10.3.253;
destination-region none;
user any;
category any;
application/service any/any/any/any;
action allow;
icmp-unreachable: no
terminal yes;
}
Diagram for reference: https://imgur.com/a/dsXoBKJ
12-01-2020 04:00 PM - edited 12-01-2020 04:05 PM
There will likely be a conflict on the internal network as to where packets need to be routed. Hosts may receive packets from the asa, but will use their default gateway to reply, causing a loop which the firewall won't like
This could be solved by having the ASA source NAT all outgoing packets behind it's internal IP
Some more details might help as it's not entirely clear what the intention of this setup is, with the ASA having one leg on the internal network
I think, if I understand your setup correctly, your design may fare better if you add the asa external interface on the outside ISP link, and connect the internal interface to the dmz interface on the Palo
12-01-2020 03:02 PM
Good Day
I am re-reading your message about 5x now and it is not really clear what the issue is.
Perhaps you could explain.
I understand you did a tracert from a Windows machine:
C:\Users\sferguson>tracert -d 208.64.237.43 Tracing route to 208.64.237.43 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.10.3.111 2 22 ms 22 ms 23 ms 208.64.237.43
So what was the default gateway on this windows machine... 10.10.3.111 or 10.10.10.253?
What was the IP of the Windows computer?
Did you do your test from the LAN zone?
After this, I am just looking at what appears to be OK routing table entries.
Can you describe how the traffic is supposed to flow, stating what the Src IP is supposed to be, and how the traffic is supposed to route, hitting interface, using what IP, etc.
I think your issue is simple to resolve, but right now, I cannot understand what is broken.
12-01-2020 04:00 PM - edited 12-01-2020 04:05 PM
There will likely be a conflict on the internal network as to where packets need to be routed. Hosts may receive packets from the asa, but will use their default gateway to reply, causing a loop which the firewall won't like
This could be solved by having the ASA source NAT all outgoing packets behind it's internal IP
Some more details might help as it's not entirely clear what the intention of this setup is, with the ASA having one leg on the internal network
I think, if I understand your setup correctly, your design may fare better if you add the asa external interface on the outside ISP link, and connect the internal interface to the dmz interface on the Palo
12-02-2020 06:39 AM
I believe you're correct on the loop with the ASA, and it makes sense when you explain it like that.
To make thing as simple as possible, I've set the ASA up on it's own subnet, and the Palo will simply handle all routing between the subnet.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!