I am curious as to how rpf works on the pix. I found the description in the command ref. to be somewhat vague, and am hoping someone can explain the following points on rpf Ingress filtering :
Ingress filtering checks inbound packets for source ip address integrity, it does this by looking up a reverse route in local routing table, which must exist or the packet is dropped. I don't understand what the pix is looking up in the routing table , ie how does the local routes in the table relate to telling if the SA is legitimate or spoofed ?
the PIX inside interface has 2 connected networks, 172.16.1.0, and 192.168.1.0
one is directly connected , the other has a route statement via inside
these networks are being address translated to the outside interface public ip 18.104.22.168
rpf is configured for the outside interface
Question 1: a legitimate packet comes in with a SA of 22.214.171.124 destined for 126.96.36.199, with a nat mapping to 172.16.1.23. What is the pix doing and comparing when checking the route table to verify this is a legitimate packet ? How does NAT figure into the picture ?
Question 2 : another packet, but this time the SA of 188.8.131.52 was spoofed in a DOS attack, destined for the outside interface, 184.108.40.206,
how is this packet compared and dropped ?
Question 3 : What is the signifigance of the default route ( in regards to rpf only) ?
I would greatly appreciate any comments on how rpf works in this example
In a nutshell, RPF allows a router or firewall to ask itself the question "Am I receiving this packet on the same interface that I would use if I was forwarding traffic to the source of the packet" If the answer to the question is yes, the packet passes RPF, if the answer is no, the packet fails RPF. NAT becomes largely irrelevant, all that RPF is doing is ensuring that the traffic arrived from the "right direction"
With reference to the default route (and your network design) leading to the internet. What this means is that traffic arriving on your outside interface with any source address other than those connected/routed on your inside interface will pass RPF, again, the logic here is that the packet has arrived from the "right direction" based on the routing table, and in this case, the default route.
My own question here has to do with RPF on routers, and I'm wondering if there is any plan to modify the RPF/extended access-list functionality so that the RPF ACL can genuinely be used to inspect all components of a packet that has failed RPF, including source/destination/port etc. Also, I've encountered problems getting RPF access-list logging to work properly and wonder if anyone can throw some light on it.
I think that gives me a better picture, it seems that the real functionality of rpf would come from a scenario where it was deployed on, say, an ISP edge router as ingess and egress filtering. It won't do a whole lot for a SOHO network other than prevent ip spoofing of their internal subnet(s) correct ?
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :