- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Echo replies dropped – spoofed address
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Echo replies dropped – spoofed address
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>;
- 10.254.3.63 is the IP address of the server on my peers network.
- Is it being blocked because it sees it as a spoofed address?
- Can I have create an exception for the object 10.254.3.63 to allow it through?
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
March 27th with sessions for both the EMEA and Americas time zones
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
