Hi,
I have an ASA2110 for multiple VPN customer's which are accessing different servers in our cloud environment.
I will make this as simple as I can, my scenario is like this:
1 - On the ASA there is a DMZ sub-interface configured on 192.168.56.0/24 subnet.
interface Ethernet1/2.2721
vlan 2721
nameif vpn-xxx-xxx
security-level 90
ip address 192.168.56.1 255.255.255.0
2 - This interface is the default gateway for the servers in our cloud, and there is a VPN connection for the customer ( using 192.168.1.0/24 subnet locally) to connect on ASA using ikev2 and then access the servers on 192.168.56.0/24 subnet.
3 - No there is another customer who needs access to 172.20.67.0/24 ( cloud server subnet) via VPN coming from a remote subnet of 192.168.56.0/24 (his local subnet)
interface Ethernet1/2.2782
vlan 2782
nameif vpn-xxx-xxx
security-level 90
ip address 172.20.67.131 255.255.255.0
4 - VPN gets connected no issues but when they access 172.20.67.0/24 from 192.168.56.0 network it doesn't work because on the ASAs routing table 192.168.56.0/24 is a connected route
C 192.168.56.0 255.255.255.0
is directly connected, vpn-xxx-xxx
5 - Now as an alternate I have configured PBR in a way that anything coming from source 172.20.67.0/24 going to 192.168.56.0/24 will go via outside interface (VPN).
route-map xxx-pbr-map permit 10
match ip address xxx-pbr
set ip next-hop xxx.xxx.xxx.xxx ---- IP of the outside Interface gateway
access-list xxx-pbr extended permit ip 172.20.67.0 255.255.255.0 192.168.56.0 255.255.255.0
Then I have called that route-map on the interface Ethernet1/2.2782 (172.20.67.131).
Now I can see the access-list xxx-pbr having matches, and when I check traffic flow in packet tracer tool in ASA it does PBR-LOOKUP and it matches with the route-map defined but still use the global routing table which has 192.168.56.0/24 as connected interface.
The question is, does PBR works for remote subnet if there is a connected interface with the same IP address.
I think it will not work as the connected interface will take precedence always but then what's the use of source-based routing if there is no workaround for this scenario!!!!
