1. Home
  2. Cisco Systems
  3. Cisco PIX 501 (6.3.5) message 106021: Deny udp reverse path check from x.x.x.x to x.x.x.x

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

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)

Reply to
zii kell
Loading thread data ...

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".

Reply to
Lutz Donnerhacke

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?

Reply to
zii kell

Oh, sorry. I usually assume configurational errors first.

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

Reply to
Lutz Donnerhacke

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.

Reply to
AMR

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.)

Reply to
Walter Roberson

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

Reply to
zii kell

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.