05-12-2021 11:49 PM
HI
We have a Site to Site VPN configured between our FTD and a 3rd Party.
1. I have a rule allowing inbound from Outside from 3rd party peer to internal servers whcih should bring up the VPN between the peer addresses,
2. Do I need a rule from inside to outside also, We never did have on ASA because its the 3rd party that initiates and we respond.
3. Also the sysopt option is checked so do i even need and ACP rule.
4. Do I need a NAT Exemption rule, I cant see that I would because this traffic dosent match an existing NAT rule.?
Thanks
Solved! Go to Solution.
05-13-2021 02:43 AM
Ok so I assume this VPN has never worked then? I assumed by the initial post you just wanted confirmation on the ACP and NAT configuration.
You've probably got a VPN configuration issue between yourself and the 3rd party, you both need to double check your IKE and IPSec settings and the PSK.
Pinging the peer from the FTD itself won't bring up the tunnel, only interesting traffic (as defined in the VPN topology) can establish a tunnel. As you are only permitting traffic from outside to inside, the peer will need to generate the traffic.
Turn on ikev1 or ikev2 debugs (wheatever you are using), generate some traffic (as per the networks defined in the VPN topology) and provide the output for review.
05-13-2021 12:16 AM
Hi @benolyndav
If the remote peer is initating the traffic then you don't explicitly need to permit the return traffic (inside to outside).
As default, yes you would need an ACP rule.
Normally you would need a NAT exemption rule for Site-to-Site VPN traffic, you would usually a Dynamic PAT rule for internet access from inside to outside which the return traffic could match and be unintentially translated.
Run packet-tracer to simulate and confirm.
05-13-2021 02:00 AM
Hi Rob
I run a packet-tracer
selecting outside interface and selecting one of 3rd party servers as source and our server as destination tese two are part of the protected networks
it gets dropped reason (tunnel pending)/snp_sp_action_cb:1748
the acl in the trace says allow
05-13-2021 02:06 AM
Seems like the tunnel is pending. With a VPN and packet-tracer you need to run the same command twice, once to establish the tunnel and the second to determine whether it is working as expected.
Provide the full output of packet-tracer if possible
Check "show crypto ipsec sa" to determine whether a tunnel is established and if the encaps|decaps counters are increasing.
05-13-2021 02:20 AM
Hi
I ran it again and still same result
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop x.x.x.x using egress ifc _INSIDE
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip ifc _OUTSIDE object-group BABOK-VPN-REMOTE-HOSTS ifc _INSIDE object-group BABOK-VPN-LOCAL-HOSTS rule-id 268438961
access-list CSM_FW_ACL_ remark rule-id 268438961: ACCESS POLICY: -NCHS-POLICY - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268438961: L7 RULE: BABOK_VPN_Rule
object-group network BABOK-VPN-REMOTE-HOSTS
network-object object BABOK-Terminal-Server
network-object object BABOK-Solarwinds-Server
object-group network BABOK-VPN-LOCAL-HOSTS
network-object object FDH-STG
network-object object FDH-MON1
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Result:
input-interface: _OUTSIDE
input-status: up
input-line-status: up
output-interface: _INSIDE
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x000000aab0bc20ec flow (tunnel-pending)/snp_sp_action_cb:1748
05-13-2021 02:26 AM
It's dropped in Phase 7 VPN, so possibly isn't an ACP issue.
Has the tunnel even been established? Provide the output of "show crypto ipsec sa"
05-13-2021 02:36 AM
There are no ipsec sas for peer x.x.x.x
never is
05-13-2021 02:37 AM
I can ping the peer but the tunnel never comes up.?
05-13-2021 02:43 AM
Ok so I assume this VPN has never worked then? I assumed by the initial post you just wanted confirmation on the ACP and NAT configuration.
You've probably got a VPN configuration issue between yourself and the 3rd party, you both need to double check your IKE and IPSec settings and the PSK.
Pinging the peer from the FTD itself won't bring up the tunnel, only interesting traffic (as defined in the VPN topology) can establish a tunnel. As you are only permitting traffic from outside to inside, the peer will need to generate the traffic.
Turn on ikev1 or ikev2 debugs (wheatever you are using), generate some traffic (as per the networks defined in the VPN topology) and provide the output for review.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide