cisco ipsec VPN force ALL traffic down tunnel

[RabbieBurns]

Ive got a remote site and a IPSec from the ADSL router/modem thing there, connected back to the main site. Its working fine for local traffic.

Now I want it modified and force all traffic down the tunnel, so the internet browsing is filtered by our appliance at the main site. Our ISP are struggling to achieve this (its their box) so I'm hoping there is someone a bit more cluued up than them here who can write me the commands needed for this so I can tell them tomorrow.

The main site is 10.0.0.0/16 and the remote site is 10.1.0.0/16

[AngryTechnician]

If you set the default gateway on the client to the gateway on the remote LAN, that should do it.

[RabbieBurns]

I would have thought that, but it doesn't seem to work..

On the firewall/router in the main site (its a fortinet device) im running a trace and I dont see any packets from the test source client (10.2.0.101) on any interface except for packets destined to a 10.0.0.0 address.

so if i ping 10.0.0.1 from the remote 10.2.0.101 client, the ping is sucessful and I can see these packets in the trace log.

If i ping 8.8.8.8 from the remote 10.2.0.101 client, i dont even see them at the other end of the vpn tunnel on the fortinet device.

Doesnt there need to be some sort of ACL on the cisco that says if the packet is destined to 8.8.8.8 that it sends it down the vpn tunnel, even if the client 10.2.0.101 has the defualt gateway of 10.0.0.1 ?

edit: added more

[RabbieBurns]

Here is some parts of the config on the cisco:

...
crypto isakmp policy 1
 encr 3des
 authentication pre-share
 group 2
crypto isakmp key SCHOOLNAMEVPN address 123.123.123.123

!
!
crypto ipsec transform-set SCHOOLNAME esp-3des esp-sha-hmac 
!
!
crypto map SCHOOLNAME 10 ipsec-isakmp 
 description "IPSec to MainSite"
 set peer 156.156.156.156
 set transform-set SCHOOLNAME 
 match address 110
...

interface Loopback100
 no ip address
 ip nat inside
 ip virtual-reassembly in
!
interface Ethernet0
 no ip address
 shutdown
 no fair-queue
interface ATM0
 no ip address
 no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
 pvc 8/35 
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
 !
...
interface Vlan1
 description "LAN interface"
 ip address 10.2.0.1 255.255.0.0
 ip nat inside
 ip virtual-reassembly in
!
interface Dialer0
 no ip address
!
interface Dialer1
 description "WAN 021234567"
 ip address negotiated
 ip virtual-reassembly in
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname blah@rdsln02
 ppp chap password 0 blahblah
 no cdp enable
 crypto map SCHOOLNAME
!
...
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip nat inside source list NAT interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1

!
ip access-list extended NAT
 deny   ip 10.2.0.0 0.0.255.255 192.168.1.0 0.0.0.255
 deny   ip 10.2.0.0 0.0.255.255 10.0.0.0 0.0.255.255
 deny   ip 10.2.0.0 0.0.255.255 any
!
access-list 110 permit ip 10.2.0.0 0.0.255.255 10.0.0.0 0.0.255.255
access-list 110 permit ip 10.2.0.0 0.0.255.255 any
access-list 110 permit ip any 10.2.0.0 0.0.255.255
dialer-list 1 protocol ip permit
!

I think thats the relevent parts...

Should that be working for what I described in OP? Looking at this thread here https://supportforums.cisco.com/thread/2052719 it talks about adding cryptomap acl etc is that what is required here?

[SYNACK]

You may need to do a show IP route on the router to see what it's routing table is doing, currenly from the above config it has the default route set to dialer 1 which appears to be the DSL link with VPN over it so it should probably be doing what you are after.

Is the other end of the tunnel setup to allow traffic outside the local network there? If not the device could be killing unroutable packets when it gets them.

You can also try a tracert/traceroute on a remote client / the remote router to 8.8.8.8 to see where it is trying to send the packets.

[RabbieBurns]

from a remote pc a tracert just goes to 10.2.0.1 and then * * * *

The other end is our main internet connection here and that device is all configured to allow internet from the tunnel interface in and out.

When i run a packet diagnostic on the device at the main end, i dont even see any packets coming from the 10.2.0.0 subnet except local traffic.

I will try to get a copy of the routing table.

[RabbieBurns]

Also, what are the access list deny statements doing?

[SYNACK]

Also, what are the access list deny statements doing?

Weird, are you sure it works for local traffic?

The ACL appears to be blocking any traffic from the 10.2.x.x network from being natted if it is going to the 10.0.x.x, 192.168.x.x and the final statment kills any natting from 10.2.x.x to anywhere. If I remember correctly the source ACL should permit the host you want to be able to use NAT otherwise there is no point.

How is the remote end configured. Is it giving out a single IP which is then being NATted at the remote site so that they all share that IP or are you routing between the two networks. If so does the fortinet have a route for 10.2.x.x pointing back down the tunnel?

[RabbieBurns]

yup works for local traffic, but there would be no NAT needed for local traffic only traffic destined for the internet ?

I Can ping 10.2.0.2 (a remote desktop) from my desktop 10.0.0.x and vice versa. There is routing between the networks, the remote cisco is a local dhcp server for that network. Static route to 10.2.0.0 is configured on the fortigate.

[SYNACK]

So that NAT stuff should actually be doing nothing I think however I could be wrong and it may be applying NAT to everything but those networks. Given the setup you should not need to be NATing any traffic anymore as that should be done upstream by the Fortinet applience. The whole lot - short of the directly local stuff that IP will take care of anyway - should just be routed upstream to your main site and dealt with there.

[gaiacraig]

I'm assuming this is still open, so you can do this a couple of ways...

1] If there is a Cisco device at BOTH ends, use a tunnel interface at each router to send traffic via the IPSec VPN. This way you just add a route statement to send all traffic via the Tunnel interface.

2] Look at this... https://supportforums.cisco.com/thread/2045344

The article at Cisco's Support Forums describes exactly what you need if the ISP doesn't have a Cisco router at the other end of the link.

Hope that helps!