Echo replies dropped – spoofed address

[ohareka]

Hello,

• I have a site to site VPN setup between FW1 and a Peer FW (10.254.x.x) that works ok.   The peers are up and i can ping his server 10.254.3.63 from FW1.
• I also have a connection from FW1 to FW2 on my LAN.  I have servers on both my FW1 and FW2 and they can ping each other in both directions.  No issues.

But I need a server 172.20.2.11 on FW2 to ping a server 10.254.3.63 across the VPN to the Peer FW LAN

Pings are getting there but not getting back

• access-lists are ok on both FW1 and FW2
• Routing seems ok and the firewall was also reloaded
• changing IP spoofing to detect only              DIDNT WORK
  fwaccel off                                                         DIDNT WORK
  fwaccel on                                                         DIDNT WORK

fw ctl zdebug + drop | grep 10.254.3.63
@;223550018;[cpu_1];[SIM-205033127];sim_pkt_send_drop_notification: (0,0) received drop, reason: spoofed address - monitor only, conn: <10.254.3.63,0,172.20.2.11,1,1>;

1. 10.254.3.63 is the IP address of the server on my peers network. 
2. Is it being blocked because it sees it as a spoofed address? 
3. Can I have create an exception for the object 10.254.3.63 to allow it through?

[PhoneBoy]

You need to change your anti-spoofing configuration (done on the relevant gateway object) to include that IP on the relevant interface.

[ohareka]

I tried that but it will only let me do that on the internal interface. I need to do this on the external interface. Its greyed out though. Is their any work around? The IP address i need to allow through is from a server on another companys network. The peer is up but its dropping their server IP

[Timothy_Hall · Accepted solution]

On the external interface of the firewall under Anti-Spoofing there should be a checkbox with "Don't check packets from" next to it.  Check that box (click Override at the top of the screen if you need to) and add 10.254.3.63 to it.  If you can't do this for some reason, you need to redefine FW1's internal topology to not contain 10.254.3.63 at all (including FW1's VPN domain), use the special object type "Group with exclusion" to do this.

[ohareka]

Thanks for your help everyone. I was just missing the subnet 10.254.3.63 from the eth2 topology interface. Once i put that in i was able to ping successfully.

[Mike_A]

Wouldn't a route out eth2 for 10.254.3.0/24 (or however he wants to add that), suffice for this?

What do your routes for 10.0.0.0/8 look like on FW2? Assuming the 172.20.1.1 interface is external, you have a 10.0.0.0/8 route going towards the left of your diagram into your LAN (well call that eth1 for now) and 0.0.0.0/0 going out eth2 which is external? I believe you can ping the peer because it is a public IP and FW2 eth2 interface is in fact external, that is expected. 

If that is correct then FW2 is assuming all 10.0.0.0/8 traffic is supposed to source on eth1 (used as example above) and for this 10.254.3.63 its sourcing in on eth2, which is why Anti-Spoofing is kicking in. 

If it isn't to much trouble, I would add a route for 10.254.3.63/32 (as a test) on FW2 to next hop towards FW1. If you want to route the entire /24, or whats in the encryption domain, ill let you decide. 

set static-route 10.254.3.63/32 nexthop gateway address 172.20.1.200 on

Install policy and try to ping 10.254.3.63 again.