Did a Wireshark capture. The TCP handshake between R1 and R2 goes well. But the TCP handshake between R2 and R3 is incomplete. R2 sends SYN and R3 sends SYN/ACK. But for some reason, R2 doesn't reply back with ACK.
With regards Kings On Sat, May 28, 2011 at 11:30 AM, Kingsley Charles < [email protected]> wrote: > Hi Tyson > > R2 sits between R1 and R3 doing NAT and TCP intercept. I am trying telnet > from R1 to R3. > > > - TCP intercept without NAT is working. > - NAT is working fine. > - I am using 12.4(15)T > > > > R1 (10.20.30.41) ------------------- (10.20.30.41) R2 > (20.10.30.42)------------------- (20.10.30.43) R3 > > *Config* > > interface GigabitEthernet0/0 > ip address 20.10.30.42 255.255.255.0 > ip nat outside > ip virtual-reassembly > duplex auto > speed auto > > interface GigabitEthernet0/1 > ip address 10.20.30.42 255.255.255.0 > ip nat inside > ip virtual-reassembly > duplex auto > speed auto > > ip nat inside source static 10.20.30.41 20.10.30.41 > > access-list 123 permit tcp any any > ip tcp intercept list 123 > > router2#sh access-lists 123 > Extended IP access list 123 > 10 permit tcp any any (22 matches) > > > *debug ip nat O/P* > > *May 28 03:18:30.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [1128] > *May 28 03:18:30.804: NAT: s=20.10.30.43, d=20.10.30.41->10.20.30.41 [8733] > *May 28 03:18:30.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [1129] > *May 28 03:18:30.808: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32289] > *May 28 03:18:30.808: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [1130] > *May 28 03:18:31.804: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32290] > *May 28 03:18:31.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [1131] > *May 28 03:18:32.644: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18699] > *May 28 03:18:32.804: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32289] > *May 28 03:18:32.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18700] > *May 28 03:18:33.804: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32290] > *May 28 03:18:33.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18701] > *May 28 03:18:36.320: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18699] > *May 28 03:18:36.804: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32289] > *May 28 03:18:36.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18700] > *May 28 03:18:37.804: NAT*: s=20.10.30.43, d=20.10.30.41->10.20.30.41 > [32290] > *May 28 03:18:37.804: NAT*: s=10.20.30.41->20.10.30.41, d=20.10.30.43 > [18701] > > > > *debug ip packet O/P* > > *May 28 03:19:16.380: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:16.380: IP: tableid=0, s=20.10.30.43 (local), d=10.20.30.41 > (Gigab > itEthernet0/1), routed via FIB > *May 28 03:19:16.380: IP: s=20.10.30.43 (local), d=10.20.30.41 > (GigabitEthernet0 > /1), len 40, sending > *May 28 03:19:16.384: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:16.384: IP: s=20.10.30.41 (local), d=20.10.30.43 > (GigabitEthernet0 > /0), len 44, sending > *May 28 03:19:16.384: IP: tableid=0, s=20.10.30.43 (GigabitEthernet0/0), > d=10.20 > .30.41 (GigabitEthernet0/1), routed via FIB > *May 28 03:19:16.384: IP: s=20.10.30.43 (GigabitEthernet0/0), d=10.20.30.41 > (Gig > abitEthernet0/1), g=10.20.30.41, len 44, forward > *May 28 03:19:16.384: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:17.384: IP: s=20.10.30.41 (local), d=20.10.30.43 > (GigabitEthernet0 > /0), len 44, sending > *May 28 03:19:17.384: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:18.220: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:18.384: IP: tableid=0, s=20.10.30.43 (GigabitEthernet0/0), > d=10.20 > .30.41 (GigabitEthernet0/1), routed via FIB > *May 28 03:19:18.384: IP: s=20.10.30.43 (GigabitEthernet0/0), d=10.20.30.41 > (Gig > abitEthernet0/1), g=10.20.30.41, len 44, forward > *May 28 03:19:18.384: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:19.384: IP: s=20.10.30.41 (local), d=20.10.30.43 > (GigabitEthernet0 > /0), len 44, sending > *May 28 03:19:19.384: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > router2# > router2#u > *May 28 03:19:21.896: IP: tableid=0, s=20.10.30.41 (GigabitEthernet0/1), > d=20.10 > .30.43 (GigabitEthernet0/0), routed via FIB > *May 28 03:19:22.384: IP: tableid=0, s=20.10.30.43 (GigabitEthernet0/0), > d=10.20 > .30.41 (GigabitEthernet0/1), routed via FIB > *May 28 03:19:22.384: IP: s=20.10.30.43 (GigabitEthernet0/0), d=10.20.30.41 > (Gig > abitEthernet0/1), g=10.20.30.41, len 44, forward > > > With regards > Kings > > > On Fri, May 27, 2011 at 6:51 PM, Tyson Scott <[email protected]> wrote: > >> I did it in lab 2 of volume 1 so it works in that instance. Please >> provide config and debugs >> >> Regards, >> >> Tyson Scott >> CCIE # 13513 (R&S, Security, SP) >> Managing Partner/Technical Instructor - IPexpert Inc. >> [email protected] >> >> >> >> ----- Reply message ----- >> From: "Kingsley Charles" <[email protected]> >> Date: Fri, May 27, 2011 7:35 am >> Subject: [OSL | CCIE_Security] ip tcp intercept with NAT doesn't work >> To: "Tyson Scott" <[email protected]> >> Cc: "[email protected]" < >> [email protected]> >> >> >> NAT translation and IP communication happens bidirectional. >> >> I think, tcp intercept is not compatible with NAT. >> >> Wit regards >> Kings >> >> On Fri, May 27, 2011 at 10:02 AM, Tyson Scott <[email protected]> >> wrote: >> >> > what is the output of a debug ip nat and debug ip packet when this is >> > occuring. >> > >> > >> > >> > Change everything to static routing and disable everything else to >> minimize >> > the amount of other traffic being seen. >> > >> > >> > >> > Regards, >> > >> > >> > >> > Tyson Scott - CCIE #13513 R&S, Security, and SP >> > Managing Partner / Sr. Instructor - IPexpert, Inc. >> > Mailto: [email protected] >> > Telephone: +1.810.326.1444, ext. 208 >> > Live Assistance, Please visit: www.ipexpert.com/chat >> > eFax: +1.810.454.0130 >> > >> > >> > >> > IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, >> > Audio Tools, Online Hardware Rental and Classroom Training for the Cisco >> > CCIE (R&S, Voice, Security & Service Provider) certification(s) with >> > training locations throughout the United States, Europe, South Asia and >> > Australia. Be sure to visit our online communities at >> > www.ipexpert.com/communities and our public website at www.ipexpert.com >> > >> > >> > >> > *From:* [email protected] [mailto: >> > [email protected]] *On Behalf Of *Kingsley >> Charles >> > *Sent:* Wednesday, May 18, 2011 8:18 AM >> > *To:* [email protected] >> > *Subject:* [OSL | CCIE_Security] ip tcp intercept with NAT doesn't work >> > >> > >> > >> > Hi all >> > >> > R2 is doing NAT and translating R1's IP address. R3 can see only R1's >> post >> > NAT address. >> > >> > >> > R1 ---------------- R2 ----------------- R3 >> > >> > >> > Now either, if I try to telnet from R3 to R1 (NATTed address) or R1 to >> R3, >> > telnet fails. >> > >> > It seems R2 doesn't get the ACK reply back to the SYN/ACK sent by it >> after >> > intercepting. It keeps retransmitting till the timeout. >> > >> > >> > The same works with watch mode >> > >> > >> > Does this mean, ip tcp intercept in intercept mode will not work with >> NAT? >> > >> > >> > >> > >> > >> > >> > With regards >> > Kings >> > >> >> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
