Site-to-site between 100D and AWS

[Alex_K]

Hello Everyone!

I would appreciate if someone could shed some light on my issue with IPSec VPN tunnel.

I have a pretty simple setup: Local Network (10.110.0.0/16), AWS VPC (172.10.10.0/24), and 100D firewall. I downloaded configs from AWS and build 2 redundant tunnels, which are up and passing "some" traffic. Everything is setup to pass all traffic from and to AWS without any explicit rules. I do interface-based VPN, so static route is setup to send all 172.10.10.20/24 traffic to VPN interface. The problem I'm having is that I can ping from AWS anything on 10.110.0.0 network, but I can't ping any AWS instances from my LAN.

I'm using "diagnose sniffer packet "MY_INTERFACE"" to see what's going on with the traffic and what I found out is, when I ping from my LAN, sniffer shows "279.429024 169.254.X.X -> 172.10.10.222: icmp: echo request" and I don't get any replies. However, if I specify source interface for my pings to be my firewall's local IP, I get replies back and sniffer shows the following "1208.781932 10.110.1.200 -> 172.10.10.222: icmp: echo request, 

1208.821932 172.10.10.222 -> 10.110.1.200: icmp: echo reply".

I have similar tunnels (and they work as expected) from other locations and everything looks the same to me (I didn't setup original firewalls, but I built the network infrastructure in Amazon, so all static routes in Amazon are correct).

Thank you in advance!

[ede_pfau]

hi,

and welcome to the forums.

You are using an APIPA IP address for your PC which is not routed across the tunnels. Supply a correct IP address from the local 10.110.1.x subnet and I bet it'll work.

[Alex_K]

ede_pfau

I have a layer3 switch (10.110.1.1) in my LAN which has only one vlan setup 10.110.0.0/16 and route all 0.0.0.0 traffic to 10.110.1.200 (FW). So all computers that have static IPs with 10.110.1.1 as their default gateway have no issues communicating with each other and internet thru FW.

Also, it doesn't matter if I'm pinging from a computer connected to the switch or from FW using its console.

[emnoc]

The diag debug flow filter command is your friend in this . It's probably due to a fwpolicy or snat enabled where it should be not. Ede is 100% in the earlier diagnostic but I would do a diag debug flow with a filter on the source /destination and review any output.

[Alex_K]

emnoc NAT Traversal is Enabled for the actual tunnel. I tried Enable, Disable, Forced but that doesn't seem to make any difference. Phase 2 Selector for this tunnel has 10.110.0.0/16 as the Local Subnet and 172.10.10.0/24 as the Remote Subnet. Policy & Objects->IPv4 Policy has only NAT enabled between MGMT interface (which is connected to the switch) and WAN. any to Amazon and Amazon to any allows all without NAT. So in total I have only 3 policies. Network->Static Routes has only 2 static routes and Network->Policy Routes is empty.   Here's the output when I try to ping 172.10.10.222 from FW console:  

2016-04-25 10:48:07 id=20085 trace_id=1 func=print_pkt_detail line=4717 msg="vd-root received a packet(proto=1, 169.254.X.X:3328->172.10.10.222:8) from local. code=8, type=0, id=3328, seq=0." 2016-04-25 10:48:07 id=20085 trace_id=1 func=init_ip_session_common line=4868 msg="allocate a new session-00047c1a" 2016-04-25 10:48:07 id=20085 trace_id=1 func=ipsecdev_hard_start_xmit line=157 msg="enter IPsec interface-Amazon-1" 2016-04-25 10:48:07 id=20085 trace_id=1 func=ipsec_common_output4 line=764 msg="No matching IPsec selector, drop"

[emnoc]

Can you run a new trace  for the flow ? We need to see the fwpolicy-id and the following ""No matching IPsec selector, " means that  src_id is NOT part of the encryption domain if I had to guess.

[Alex_K]

I'm not sure how to see the fwpolicy_id, but it looks like my previous flow shows everything it can, as I'm only filtering by the ip addr. As far as the actual error "No matching IPsec selector", it is valid, because I don't have 169.254.X.X as the local subnet or IP as one of my Phase 2 selectors. The question is why do I have to add that address to selectors' list? It is the IP of my side of the tunnel.

If I do: execute ping-options source 10.110.1.200

execute ping 172.10.10.222

I get this flow:

2016-04-25 12:07:43 id=20085 trace_id=61 func=print_pkt_detail line=4717 msg="vd-root received a packet(proto=1, 10.110.1.200:3328->172.10.10.222:8) from local. code=8, type=0, id=3328, seq=0." 2016-04-25 12:07:43 id=20085 trace_id=61 func=init_ip_session_common line=4868 msg="allocate a new session-00001847" 2016-04-25 12:07:43 id=20085 trace_id=61 func=ipsecdev_hard_start_xmit line=157 msg="enter IPsec interface-Amazon-1" 2016-04-25 12:07:43 id=20085 trace_id=61 func=esp_output4 line=846 msg="IPsec encrypt/auth" 2016-04-25 12:07:43 id=20085 trace_id=61 func=ipsec_output_finish line=496 msg="send to 170.55.X.X via intf-wan2" 2016-04-25 12:07:43 id=20085 trace_id=62 func=print_pkt_detail line=4717 msg="vd-root received a packet(proto=1, 172.10.10.222:3328->10.110.1.200:0) from Amazon-1. code=0, type=0, id=3328, seq=0."

[emnoc]

Here's what you can do;

1: craft a policy with a snat pool of a valid address that's allowed across the tunnel  (amazon-1 )

2: enable it ahead of the existing fwpolicies for "Amazon-1"

3: does it work when you ping from that host.

To answer the other question; your APIPA address is not part of the encryption domain hence it will generate a phase2 selector ( ispec error )

what do you have allow for tunnel Amazon-1  ( 172.16.10.0/24 )?

[ede_pfau]

I mean, the questions are what is this APIPA address coming from, and why would a valid host use it? I would not recommend adding the APIPA subnet to the phase2 QM selectors. Try to find the reason this address is used in the first place.

[Alex_K]

ede_pfau

If you mean this address "169.254.X.X" then it's not APIPA - it is /30 ends of the tunnel, which were provided by Amazon.

Thanks everyone for your suggestions, I finally got it working. Here's what I did:

I double-triple checked my config and while I was tinkering with it I deleted Amazon Local to Remote policy from Policy & Objects->IPv4 Policy by mistake. I then re-added THE EXACT SAME policy and it started working!! I have no idea what was it, but I haven't changed anything else besides that. Could that be a glitch? I'm not sure.

While working on it, I also noticed that I have negotiation failures in progress IPsec phase 2:

 

I'm not sure if these errors affect the tunnel but I'd like to be able to resolve them. All settings (keylife, ike, etc) match both sides of the tunnel and traffic seems to be flowing ok, but I'm still worried.