Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

Jun 11, 2007 6 Replies

Dear all,



My PIX 501 6.3.5 log shows these errors. Would someone be able to explain what these mean in laymans' terms?


106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51 on interface inside
106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on interface inside
106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51 on interface inside
106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on interface inside
106021: Deny udp reverse path check from 192.168.255.1 to 62.140.29.51 on interface inside
106021: Deny udp reverse path check from 192.168.81.1 to 62.140.29.51 on interface inside

My internal network uses 10.9.9.0/24 and there are no devices that should be connected inside using 192.168.x.x.



I decided to nmap the address 62.140.29.51 to see what sort of box it was:


135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
1025/tcp open NFS-or-IIS
4000/tcp open remoteanything
12000/tcp open cce4x
53/udp open|filtered domain
69/udp open|filtered tftp
135/udp open|filtered msrpc
136/udp open|filtered profile
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
161/udp open|filtered snmp
162/udp open|filtered snmptrap
177/udp open|filtered xdmcp
445/udp open|filtered microsoft-ds
500/udp open|filtered isakmp
1900/udp open|filtered UPnP
4500/udp open|filtered sae-urn
5000/udp open|filtered UPnP
5002/udp open|filtered rfe
5003/udp open|filtered filemaker Device type: general purpose Running: Microsoft Windows NT/2K/XP OS details: Microsoft Windows 2000 SP3 OS Fingerprint: OS:SCAN(V=4.20%D=6/10%OT=1025%CT=1%CU=%PV=N%DS=15%G=Y%TM=466C733A%P=i686-pc OS:-windows-windows)T1(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)T1(Resp=Y%DF=Y OS:%W=FFFF%ACK=S++%Flags=AS%Ops=MNWNNT)T1(Resp=N)T2(Resp=Y%DF=N%W=C00%ACK=S OS:%Flags=AR%Ops=WNMETL)T2(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T2(R OS:esp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=400%ACK=S++ OS:%Flags=AR%Ops=WNMETL)T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T3 OS:(Resp=Y%DF=N%W=1000%ACK=S++%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=C00%ACK OS:=S%Flags=AR%Ops=WNMETL)T4(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=WNMETL)T4 OS:(Resp=Y%DF=N%W=C00%ACK=S%Flags=AR%Ops=WNMETL)T5(Resp=Y%DF=N%W=0%ACK=S++% OS:Flags=AR%Ops=)T6(Resp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y% OS:DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)T6(Resp=Y%DF=N%W=400%ACK=S%Flags=AR OS:%Ops=WNMETL)T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%D OS:F=N%W=C00%ACK=S++%Flags=AR%Ops=WNMETL)T7(Resp=Y%DF=N%W=1000%ACK=S++%Flag OS:s=AR%Ops=WNMETL)PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UC OS:K=F%ULEN=134%DAT=E)

Network Distance: 15 hops



OS detection performed. Please report any incorrect results at

formatting link
. Nmap finished: 1 IP address (1 host up) scanned in 77.016 seconds Raw packets sent: 3468 (131.180KB) | Rcvd: 3296 (168.400KB)


Due to errornous network design, routing or static rules the PIX receives the 192.168.255.1 addresses from the inside interface. The routing table of the PIX (show route) does not show an approbriate entry for this network pointing to interface "inside".

Why would the pix have a route for this subnet (192.168) when this range is not used inside? Could this indicate that someone has connected a device with 192.168.x.x onto the inside network?

Oh, sorry. I usually assume configurational errors first.

Of course, there might be an internal client using this address.

at

formatting link
Nmap finished: 1 IP address (1 host up) scanned in 77.016 seconds

Possible spoof/dos attempt. That error message tells me that uRPF is enabled and doing its job. Basically, any traffic that doesn't have a path back to the source is dropped. It's not a config error - you are seeing drops from (most likely) a spoof or DoS event. A legit packet is being sent from the external address with a spoofed IP to respond to (target.) Since the PIX can't verify the path back to 192.168 it drops it.

That's what looks like is going on here.

No, then it would show "interface outside". The bad packets are on the inside. "capture" could be used to find out more about them (by looking at the MAC addresses.)

I shall go and capture some packets. Hope to see some soon.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required