Hello, I have a problem with the return path of NAT'd traffic on a Cisco 877W router. Here's the network setup: gatekeeper1 (192.168.0.1) is a Cisco 857 gatekeeper2 (192.168.0.253) is a Cisco 857 gatekeeper3 (192.168.0.251) is a Cisco 877W The default route is 192.168.0.1 on all devices, however there are some static route defined so that traffic to certain IP addresses bounce off to 192.168.0.253 and use that Internet connection instead. This new connection is designed so that traffic aimed for a certain internal IP address (192.168.0.190) comes via this third internet connection in order to take the load off of the main line. NAT is all configured and appears to be working when .251 is the default route but as soon as I set it back to .1, the traffic appears to come in but doesn't go out again. Here's what I mean: gatekeeper3#sh ip nat tr Pro Inside global Inside local Outside local Outside global --- 82.x.y.10 192.168.0.2 --- --- tcp 82.x.y.9:80 192.168.0.190:80 216.x.y.246:51653 216.x.y.246:51653 --- 82.x.y.9 192.168.0.190 --- --- As you can see here, I'm trying to connect to port 80 on 82.x.y.10 (which is 192.168.0.190 internally) from 216.x.y.246 and that NAT rule seems to allow the traffic as expected plus the firewall is set to allow all traffic for the time being whilst I debug this issue. The external machine tries making the connection, the router appears to allow it but the connection never establishes. My suspicion is that the returning traffic is going out of the 'wrong' connection. How can I set this up so that the returning traffic goes out of the correct path? Thanks in advance for any help you can offer. Regards, Ade.
... View more
I’m having problems with a Cisco 877W router connected to Zen Internet in the United Kingdom; what I see happen is the router boot up, establish a connection (CD light on, PPP light on) and then after a random period of time drop the connection (CD light on, PPP light off) without being able to re-establish a connection. The router is running Cisco IOS Software, C870 Software (C870-ADVSECURITYK9-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3). The embedded firmware is 3.0.014_no_bist.bin, however I upgraded it to adsl_alc_20190_4.0.017.bin as it tends to behave with BT ADSL lines somewhat better than the factory installed version. Just to grab two random examples: 000033: *Nov 11 15:54:33.455 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up 000034: *Nov 11 15:55:56.378 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down And... 000034: *Nov 11 16:34:30.175 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to up 000035: *Nov 11 16:41:31.039 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down On the first one, I turned on PPP debugging and the following errors were logged: 000245: *Nov 11 16:08:50.033 UTC: Vi2 PPP: Phase is ESTABLISHING, Passive Open 000246: *Nov 11 16:08:50.033 UTC: Vi2 LCP: State is Listen 000247: *Nov 11 16:08:50.037 UTC: Di0 IPCP: Remove route to 62.xx.yy.zz 000248: *Nov 11 16:08:50.301 UTC: Vi2 PPP: Outbound ip packet dropped 000249: *Nov 11 16:08:51.034 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access2, changed state to down 000250: *Nov 11 16:08:52.050 UTC: Vi2 LCP: Timeout: State Listen 000251: *Nov 11 16:08:52.050 UTC: Vi2 PPP: No remote authentication for call-out 000252: *Nov 11 16:08:52.050 UTC: Vi2 LCP: O CONFREQ [Listen] id 147 len 10 000253: *Nov 11 16:08:52.050 UTC: Vi2 LCP: MagicNumber 0x1C672C6B (0x05061C672C6B) 000254: *Nov 11 16:08:54.066 UTC: Vi2 LCP: Timeout: State REQsent [repeats] 000497: *Nov 11 16:10:40.466 UTC: Vi2 LCP: Timeout: State REQsent 000498: *Nov 11 16:10:40.466 UTC: Vi2 LCP: O CONFREQ [REQsent] id 171 len 10 000499: *Nov 11 16:10:40.466 UTC: Vi2 LCP: MagicNumber 0x1C68B478 (0x05061C68B478) 000500: *Nov 11 16:10:40.891 UTC: Vi2 PPP: Outbound ip packet dropped I have an 857W currently running on the line (that works without problem) until I can solve this issue but, in a nutshell, it looks like it drops the connection, keeps the line “up” but will not re-establish PPP. I’m happy that the overall configuration is okay because until it suddenly and randomly drops the line, it behaves as it should but will post the config if it's useful. Here's what I believe to be the relevant part of the config: interface ATM0 no ip address no ip redirects no ip unreachables no ip proxy-arp ip flow ingress no atm ilmi-keepalive ! interface ATM0.1 point-to-point no ip redirects no ip unreachables no ip proxy-arp ip flow ingress pvc 0/38 encapsulation aal5mux ppp dialer dialer pool-member 1 ! interface Vlan1 description $FW_INSIDE$ ip address 192.168.192.1 255.255.255.0 no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip nat inside ip virtual-reassembly zone-member security in-zone ! interface Dialer0 description $FW_OUTSIDE$ ip address 82.xx.yy.254 255.255.255.248 no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip nat outside ip virtual-reassembly zone-member security out-zone encapsulation ppp dialer pool 1 dialer-group 1 ppp authentication chap callin ppp chap hostname [zen-hostname] ppp chap password 7 [zen-password] ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 permanent As I've mentioned, it seems to be quite happy on the 857W currently running on that circuit. As soon as I put the 877W in place, it connects once, drops then refuses to re-connect. Any pointers? Regards, Ade.
... View more