02-23-2017 08:23 AM - edited 03-12-2019 01:58 AM
Hello all..
I have a HA pair of 5516's. For historic informational purposes: these have been on the same firmware and utilizing hairpin NAT without issues for 18months+
Recently in doing some network changes, I applied PBR to the inside interface to these ASA's to push traffic to a specific internet peering device, which is the other side of the outside interface.
It's a simple statement as I wanted all traffic sourced from inside to follow this rule. So i didn't add in a match statement - my understanding is without a match statement 'any' is assumed. It also tracks the peering interfaces of the internet peering device and assuming at least one of the tracking elements was up, PBR was applied.
This has resulted in a log spam of:
"Feb 23 15:50:30 %ASA-2-106017: Deny IP due to Land Attack from <outside int IP> to <outside int IP>"
As far as i can tell, there is no actual impact, just this cosmetic log spam message. But it has only started after the PBR rule was applied.
config:
sla monitor 1
type echo protocol ipIcmpEcho yy.yy.yy.yy interface outside
timeout 1000
threshold 2
frequency 3
sla monitor schedule 1 life forever start-time now
!
sla monitor 2
type echo protocol ipIcmpEcho yy.yy.yy.yy interface outside
timeout 1000
threshold 2
frequency 3
sla monitor schedule 2 life forever start-time now
!
track 10 rtr 1 reachability
!
track 20 rtr 2 reachability
!
route-map MY-ROUTE-MAP permit 5
set ip next-hop verify-availability xx.xx.xx.xx 1 track 10
set ip next-hop verify-availability xx.xx.xx.xx 2 track 20
!
route-map MY-ROUTE-MAP permit 10
set ip default next-hop xx.xx.xx.xx
!
interface GigabitEthernetx/x
nameif inside
security-level 100
ip address xx.xx.xx.xx 255.255.255.0 standby xx.xx.xx.xy
policy-route route-map MY-ROUTE-MAP
Is not having a 'match' statement on the PBR possibly the cause? Or something else? Some advice would be appreciated.
Thanks
04-09-2017 12:42 PM
So I worked this out. The PBR was pushing (inside,inside) destined traffic through the outside interface (and subsequent NAT) and then trying to come back in from outside with the NAT'd IP.
Solved this by modifying my PBR - adding in an ACL for matching statements so PBR wouldn't apply to traffic destined for my own ranges so (inside,inside) rules would be honored properly.
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