If both devices support ipsec, you can enable encryption on the VPN there fore eliminating the risk of having a man-in-the-middle attack from your ISP. You will still have to configure a authentication key. Here is a sample config for a VPN tunnel that supports multiple protocols and multilink.
! Crypto Policy Settings ! crypto isakmp policy 1 encr 3des authentication pre-share group 2 crypto isakmp key 7Q!r$y$+xE address 172.16.226.28 crypto isakmp key 7Q!r$y$+xE address 172.16.226.27 ! ! crypto ipsec transform-set 3dessha esp-3des esp-sha-hmac mode transport ! crypto map ent1 10 ipsec-isakmp set peer 172.16.226.28 set transform-set 3dessha match address 101 crypto map ent1 20 ipsec-isakmp set peer 172.16.226.27 set transform-set 3dessha match address 102 ! access-list 101 permit gre host 172.16.132.2 host 172.16.226.28 access-list 102 permit gre host 172.16.132.2 host 172.16.226.27 ! ! GRE Tunnel Settings ! interface Tunnel0 bandwidth 8 ip address 10.1.249.2 255.255.255.0 tunnel source 172.16.132.2 tunnel destination 172.16.226.27 crypto map ent1 ! interface Tunnel1 ip address 10.1.248.2 255.255.255.0 tunnel source 172.16.132.2 tunnel destination 172.16.226.28 crypto map ent1 ! ! Crypto Map Application to Physical Interface ! interface Serial1/0 ip address 172.16.132.2 255.255.255.0 ip access-group 103 in crypto map ent1 ! ! Access-list 103 would need to be modified to both the IPSec connections ! from the corporate headquarters, as well as the GRE traffic. ! access-list 103 permit gre host 172.16.226.28 host 172.16.132.2 access-list 103 permit gre host 172.16.226.27 host 172.16.132.2 access-list 103 permit esp host 172.16.226.27 host 172.16.132.2 access-list 103 permit udp host 172.16.226.27 host 172.16.132.2 eq isakmp access-list 103 permit esp host 172.16.226.28 host 172.16.132.2 access-list 103 permit udp host 172.16.226.28 host 172.16.132.2 eq isakmp access-list 103 deny ip 10.0.0.0 0.255.255.255 any access-list 103 deny ip 192.168.0.0 0.0.255.255 any access-list 103 permit udp any host 172.16.132.50 eq domain access-list 103 permit tcp any host 172.16.132.50 eq ftp access-list 103 permit tcp any host 172.16.132.50 eq www access-list 103 permit tcp any host 172.16.132.50 eq 443 access-list 103 permit tcp any host 172.16.132.50 eq smtp access-list 103 permit icmp any 172.16.132.0 0.0.0.255 echo-reply access-list 103 permit icmp any 172.16.132.0 0.0.0.255 unreachable access-list 103 deny ip any any log -----Original Message----- From: [EMAIL PROTECTED] [mailto:StraitNo7@;aol.com] Sent: Friday, November 08, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: Remote Office VPNs My question is regarding small remote offices with <25 users. Business Class DSL has become an option for small offices since the cost is much less than a T1. I need a VPN based solution and need some advice. I am looking for your opinions of two different methods of gaining secure connectivity to a major office: 1) I know many of the draws back with using a small appliance such as a PIX or symantec appliance and allowing split tunneling (internet access directly instead of forcing them back through a vpn) but are they really that weak? 2) Should I just go with a IP based vpn from an ISP? Such as using a Cosign box at the CO and allowing the encryption to be done by the ISP? It would stay on the private backbone and not enter the public internet. Although that last mile would be unencryption just as on a frame relay.
