11-24-2020 11:23 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?
*@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.*.128.0/21 10.10.3.253 1 A S ethernet1/4
207.*.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
Thanks
11-24-2020 04:20 PM - edited 11-24-2020 06:05 PM
I assume the only way a machine can access resources through the tunnel is with static routes. Firewalls need to see everything in the 3-way handshake or they will drop traffic. In your scenario, the PA will not see the syn-ack since the return traffic bypasses the PA and returns directly to the host.
Why use an ASA for a VPN tunnel instead of just using the native capabilities of the PA? It's all standards based PAs connect to many other vendors with no issue.
Why is the inside interface of the ASA on the inside of your network instead of in a DMZ off the PA so it can filter the traffic between you and your partner?
Also, 8.0 code is end of life so you should think about an upgrade.
11-25-2020 04:15 AM
Hey thanks for replying,
I wasn't aware that they'll silently drop traffic without the 3-way.
The ASA is something the vendor insisted on, and would not have it any other way. I don't have a say in it either way.
I'll move the internal interface to it's own network segment and have the PA be the middle man for it all.
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!
