+ Post New Thread
Results 1 to 11 of 11
Wired Networks Thread, cisco ipsec VPN force ALL traffic down tunnel in Technical; Ive got a remote site and a IPSec from the ADSL router/modem thing there, connected back to the main site. ...
  1. #1

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200

    cisco ipsec VPN force ALL traffic down tunnel

    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
    Last edited by SYNACK; 22nd May 2012 at 06:29 AM. Reason: user request

  2. #2

    AngryTechnician's Avatar
    Join Date
    Oct 2008
    Posts
    3,730
    Thank Post
    698
    Thanked 1,212 Times in 761 Posts
    Rep Power
    394
    If you set the default gateway on the client to the gateway on the remote LAN, that should do it.

  3. Thanks to AngryTechnician from:

    RabbieBurns (15th May 2012)

  4. #3

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200
    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
    Last edited by RabbieBurns; 15th May 2012 at 01:23 PM.

  5. #4

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200
    Here is some parts of the config on the cisco:

    Code:
    ...
    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?

  6. #5

    SYNACK's Avatar
    Join Date
    Oct 2007
    Posts
    11,225
    Thank Post
    874
    Thanked 2,717 Times in 2,302 Posts
    Blog Entries
    11
    Rep Power
    780
    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.

  7. #6

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200
    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.

  8. #7

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200
    Also, what are the access list deny statements doing?

  9. #8

    SYNACK's Avatar
    Join Date
    Oct 2007
    Posts
    11,225
    Thank Post
    874
    Thanked 2,717 Times in 2,302 Posts
    Blog Entries
    11
    Rep Power
    780
    Quote Originally Posted by RabbieBurns View Post
    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?

  10. #9

    RabbieBurns's Avatar
    Join Date
    Apr 2008
    Location
    Sydney
    Posts
    5,527
    Thank Post
    1,339
    Thanked 470 Times in 307 Posts
    Blog Entries
    6
    Rep Power
    200
    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.

  11. #10

    SYNACK's Avatar
    Join Date
    Oct 2007
    Posts
    11,225
    Thank Post
    874
    Thanked 2,717 Times in 2,302 Posts
    Blog Entries
    11
    Rep Power
    780
    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.

  12. #11

    Join Date
    Jun 2012
    Location
    Manchester
    Posts
    12
    Thank Post
    0
    Thanked 1 Time in 1 Post
    Rep Power
    0
    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!

SHARE:
+ Post New Thread

Similar Threads

  1. [OPEN] Bug/Error: Editing a post after an embedded URL forces all new to text to be underlined
    By Dos_Box in forum EduGeek.net Site Problems
    Replies: 0
    Last Post: 26th October 2011, 09:21 AM
  2. Smoothwall Guardian IPSec VPN setup
    By psycorp in forum Internet Related/Filtering/Firewall
    Replies: 0
    Last Post: 28th June 2011, 03:31 PM
  3. L2TP/IPSEC based VPN using ISA Server
    By Norphy in forum Wireless Networks
    Replies: 2
    Last Post: 22nd June 2007, 02:13 PM
  4. VPN showdown: IPSec vs SSL vs client-less SSL
    By ITWombat in forum Wireless Networks
    Replies: 9
    Last Post: 25th September 2006, 09:35 PM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •