1841 with 3 internet connections (2xADSL, 1xbridged) help

Hello,

I have inherited a Cisco 1841 which is running the office here. I should state that I am not a Cisco guy, so i'm really appealing for help here. I have been predominantly setting things up using the flakey Cisco SDM gui, but am getting more comfortable with IOS.

Currently we have two ADSL connections, one of which (dialer0), is exclusively used for a site-to-site VPN, the other (dialer1), is for general internet use, as well as for remote access VPN users.

The first problem I have is that any remote users coming in over the VPN on dialer1 cannot see the remote subnet on the other side of the site-to-site VPN. Luckily they only need web pages, so I have put up a squid proxy in the office that they are hitting, which is then sending their requests over the site-to-site. This is obviously less than ideal.

First question - should these remote users be able to see the other side of the site-to-site, or is this behaviour expected?

My other problem is that I have a 3rd ADSL connection on a router that is in bridge mode. I would like to hook this up to the second ethernet port on the Cisco and use it for general office use (so we'd have VPN on dialer0, RA-VPN on dialer1, and webs etc on FastEthernet1). I've copied the configuration from the Draytek router it was plugged into as best I can (simply assigning that interface a static ip/mask, and telling it that it's in bridge mode RFC1483), but the one thing I can't find is how to specify a gateway for that interface - this is the only other piece of information that the Draytek asks for which the Cisco doesn't.

I know that's all a bit vague but hopefully someone else will have tried this and know where to start.

Many thanks in advance,

Jon.

Reply to
j.l.robinson
Loading thread data ...

For the third ADSL connection via Ethernet, you probably need to configure PPPOE

see Cisco doc "PPP over Ethernet Client"

formatting link

Reply to
Merv

Thanks for the reply Merv, but it's definitely not PPP - it's RFC1483 bridging, my ISP have told me this much, and they set up the bridge that I'm plugging the Cisco into. The only information I have needed on the previous router was IP address, mask, and gateway - after entering those it 'just worked'.

I'm really at a loss here.

Reply to
Jon

Interfaces don't have gateways, routes do. You need to tell the Cisco what destinations you'd like to route to over that interface. If fa0/1 has an IP address of, say, 78.86.110.27 and a netmask of 255.255.252.0, only traffic headed to 78.86.108.1 - 78.86.111.254 will be going out of fa0/1. You could send all your traffic out of that interface with:

ip route 0.0.0.0 0.0.0.0 78.86.108.1

, where 78.86.108.1 is the gateway on that network.

Reply to
alexd

Ah. Right I get it now, thanks! Should have realised that was how it works.

I can't do that though - if I do, no-one can connect to the remote access VPN, even though it's configured on dialer1. I'm guessing that all the replies are being routed out of the new default route instead of back the way they came. Does that sound likely?

I'm happy to post bits of config if that would help, but I've no idea what's relevant - I assumed as the RA-VPN is configured to listen on a certain interface, it would route all traffic that way, but it doesn't seem to be the case. I tried putting a route in for the external remote subnet that the remote access users' virtual adaptors would be on, but it makes no difference as the initial handshake isn't being done so it doesn't even get that far.

Reply to
Jon

Yes, that's probably what's happening. Static routes are a bit blunt for what you're trying to do - have a look at route maps instead:

formatting link
Think of it as a static route with an ACL. If you're lucky enough that your remote sites have static IPs, then use a route map to send all traffic to their IPs out of Dialer0. I assume your RA-VPN users are on dynamic IPs and are using a VPN client. If that's the case, use another route map to send all traffic for the VPN client protocol out Dialer1. And then you want a route map that sends everything else out Fa0/1. Hint: you can deny as well as permit in route maps.

Reply to
alexd

Going back to this point, it doesn't seem to work for me.

Here are the relevant bits of config:

interface FastEthernet0/1 description $ETH-WAN$ ip address 78.105.5.300 255.255.240.0 ip nat outside ip virtual-reassembly duplex auto speed auto

ip route 83.142.25.300 255.255.255.255 78.105.0.1 permanent

Last octets changed to 300 for purposes of this post.

With it set up like this, I can't ping 83.142.25.300 at all. If I remove the route it comes back over the default gateway.

If I plug the bridge into a PC and change my IP/subnet and gateway to the above, I can browse the internet, so it's definitely the cisco going wrong somewhere.

Any thoughts on the above?

Reply to
Jon

  1. Post the output of shovw version

  1. With the Cisco 1841 connected to the third DSL modem, post the output of show interface fa 0/1 (mask out IP address if you wish

  2. Ping he IP address configured on Fa 0/1 and see if you get a response

  1. Then ping the ISP gateway IP address

  1. Check to see if there is an ARP entry in the ARP table for the ISP gateway IP address
Reply to
Merv

Revisiting this (and I just made a similar post, but it seems to have been lost), I can't actually get this to work.

Here's what I put in my config:

interface FastEthernet0/1 description $ETH-WAN$ ip address 78.105.5.xyz 255.255.240.0 ip nat outside ip virtual-reassembly duplex auto speed auto

ip route 83.142.25.xyz 255.255.255.255 78.105.0.1 permanent

xyz is a placeholder for a real ip.

If I then try to ping 83.142.25.xyz, I get nothing. If I remove that route so that it uses the default route (and therefore another interface), it's fine.

If i connect the bridge up to a PC and put in the IP/mask and gateway, it gets straight out on the internet, so there's something on the Cisco that I'm doing wrong, definitely.

Any thoughts on the above?

Reply to
Jon

Apologies in advance for the double post which will appear in a minute.

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

London uptime is 3 days, 2 hours, 35 minutes System returned to ROM by reload at 11:57:04 UTC Tue Apr 1 2008 System image file is "flash:/c1841-advipservicesk9-mz.124-17.bin"

Cisco 1841 (revision 7.0) with 115712K/15360K bytes of memory. Processor board ID FCZ1135112M

2 FastEthernet interfaces 2 ATM interfaces 1 Virtual Private Network (VPN) Module DRAM configuration is 64 bits wide with parity disabled. 191K bytes of NVRAM. 31360K bytes of ATA CompactFlash (Read/Write)

Configuration register is 0x2102

London#show interface fa 0/1 FastEthernet0/1 is up, line protocol is up Hardware is Gt96k FE, address is 001d.46d0.d8e3 (bia 001d.46d0.d8e3) Description: $ETH-WAN$ Internet address is 78.105.5.xyz/20 MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:21, output 00:00:01, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:

0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 6969 packets input, 453412 bytes Received 6688 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog 0 input packets with dribble condition detected 31519 packets output, 3043309 bytes, 0 underruns 0 output errors, 0 collisions, 5 interface resets 0 unknown protocol drops 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

Yep, 5/5

Again 5/5

There is:

Internet 78.105.0.1 85 0090.d063.ff17 ARPA FastEthernet0/1

Jon

Reply to
Jon

So if you have connectivity to the ISP's gateway, then you should be able to access the Internet via the fa 0/1 interface given that you have NAT properly configured and routing entries are properly configured

Pickup a Internet site do a DNS lookup and gets its IP address

Configure a static IP route for that address as follows

ip route 255.255.255.255 78.105.0.1 fa 0/1

ping the site IP address using the extended ping command and specify the source interface IP address as whatever you have configured

Make sure to include the interface in the static route command so that the router will not try to reach

78.105.0.1 via another interface.

ping the site IP address using the extended ping command and specify the source interface IP address as whatever you have configured

Let us know the outcome

Reply to
Merv

This command isn't accepted - it doesn't like me specifying the interface. It will add the route find without 'fa 0/1' (I tried FastEthernet0/1 as well).

I think that it is going out of the wrong interface when trying to ping 78.105.0.1 , as it happily responds to pings from any IP.

Any thoughts? :(

Reply to
Jon

try specifying the interface before the next hop

ip route 255.255.255.255 fa 0/1 78.105.0.1

if that does not work then use ? with

ip route 255.255.255.255 ?

to see what the next paramet is theat the CLI parser will accept.

Reply to
Merv

Hi again Merv :)

Yes, that worked, here are the results:

London(config)#ip route 83.142.25.10 255.255.255.255 fa 0/1 78.105.0.1 London(config)#^Z

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 78.105.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/20 ms London#ping 83.142.25.10

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 83.142.25.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms

But from my workstation:

Pinging [83.142.25.10] with 32 bytes of data

Reply from 192.168.20.1: Destination net unreachable. Reply from 192.168.20.1: Destination net unreachable.

I don't get it! From the router it's fine, but from a workstation with the router as its gateway it isn't!

I tried a couple of traceroutes:

Tracing the route to 83.142.25.10

1 * * * 2 ge-1-1-0-64.core2.sta.lon2.coreix.net (195.66.227.58) 12 msec 16 msec 16 msec 3 ge-4-2-57.dist7b.sta.lon2.coreix.net (85.13.192.30) 12 msec 12 msec 16 msec 4 83.142.25.10 16 msec 12 msec 12 msec

London#traceroute 78.105.0.1

Type escape sequence to abort. Tracing the route to 78-105-0-1.zone3.bethere.co.uk (78.105.0.1)

1 * * * 2 * * * 3 * * *

Would this suggest that it's not actually getting through to that

78.105.0.1 gateway via the right interface?

Again very appreciative of the help.

Jon

Reply to
Jon

It looks like the ISP router ( 78-105-0-1.zone3.bethere.co.uk (78.105.0.1)) does not respond to pings; they maybe blocking - you may wish to ask about that

I like the name "bethere" - be there - apparently they are not ;-))

If you cannot ping from your workstation, it may mean that NAT is not working properly and if that is the case then the return ICMP echo replies would not make it back to your workstation.

You are getting closer to a solution though...

You may want to repost wit you complete config (sanitized of ) course and ask if there are any issue with the NAT portion of it.

Reply to
Merv

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.