05-21-2003 12:56 AM - edited 02-21-2020 12:33 PM
Hi,
I have a Cisco SOHO 97 router and i have configure VPN to acess through VPN client.
There is no problem : Client VPN connection --> OK, Access to my network --> OK
If i activate the IOS Firewall with CRWS: Client VPN connection --> OK, But I cannot access to my network.
This line is adding when i activate the firewall :
ip inspect name myfw cuseeme timeout 3600
ip inspect name myfw ftp timeout 3600
ip inspect name myfw rcmd timeout 3600
ip inspect name myfw realaudio timeout 3600
ip inspect name myfw smtp timeout 3600
ip inspect name myfw tftp timeout 30
ip inspect name myfw udp timeout 15
ip inspect name myfw tcp timeout 3600
ip inspect name myfw h323 timeout 3600
------
interface Dialer1
.....
ip access-group 111 in
ip inspect myfw out
...
--------------------------
access-list 111 permit icmp any any administratively-prohibited
access-list 111 permit icmp any any echo
access-list 111 permit icmp any any echo-reply
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any unreachable
access-list 111 permit udp any eq bootps any eq bootpc
access-list 111 permit udp any eq bootps any eq bootps
access-list 111 permit udp any eq domain any
access-list 111 permit esp any any
access-list 111 permit udp any any eq isakmp
access-list 111 permit udp any any eq 10000
access-list 111 permit tcp any any eq 1723
access-list 111 permit tcp any any eq 139
access-list 111 permit udp any any eq netbios-ns
access-list 111 permit udp any any eq netbios-dgm
access-list 111 permit gre any any
access-list 111 deny ip any any
1) When i use only ip inspect there is no problem, the VPN connection work well.
2) If i use the access-list, the network is inaccessible through VPN
I have permit ipsec with this access-list permit udp any any eq isakmp
Wich access-list must i add ??
thanks for your help
Solved! Go to Solution.
05-21-2003 01:21 AM
You have to allow both the encypted form of the traffic (which you have done with the ESP and UDP/500 access-lists), and the unencrypted form of the traffic (yes, really).
This is because the access-list is processed twice for inbound IPsec packets. The packet arives in on the interface as an IPsec packet, passes the ACL check and is decrypted within the router. At this point the router puts it back on the inbound interface to be processed accordingly. What this means though is that the unencrypted packet is then run through the ACL check again.
For VPN clients, add a line to ACL111 that says:
> access-list 111 permit ip
This is the way routers have always worked. there has been a bug to change this behaviour for quite a while now, but unfortunately would require a major change in the way IPSec packets are processed internally in the router, so it's quite a difficult fix. Bug ID is CSCdz54626 (Regular inbound ACL is processed twice for IPSec traffic).
If you're worried that this is a security risk, then don't be. If someone spoofs a packet to look like it came from your VPN pool of adresses, the first thing the router would do is recognise that this packet should have been encrypted. Since it isn't, the router will drop the packet straight away.
05-21-2003 01:21 AM
You have to allow both the encypted form of the traffic (which you have done with the ESP and UDP/500 access-lists), and the unencrypted form of the traffic (yes, really).
This is because the access-list is processed twice for inbound IPsec packets. The packet arives in on the interface as an IPsec packet, passes the ACL check and is decrypted within the router. At this point the router puts it back on the inbound interface to be processed accordingly. What this means though is that the unencrypted packet is then run through the ACL check again.
For VPN clients, add a line to ACL111 that says:
> access-list 111 permit ip
This is the way routers have always worked. there has been a bug to change this behaviour for quite a while now, but unfortunately would require a major change in the way IPSec packets are processed internally in the router, so it's quite a difficult fix. Bug ID is CSCdz54626 (Regular inbound ACL is processed twice for IPSec traffic).
If you're worried that this is a security risk, then don't be. If someone spoofs a packet to look like it came from your VPN pool of adresses, the first thing the router would do is recognise that this packet should have been encrypted. Since it isn't, the router will drop the packet straight away.
05-27-2003 04:26 PM
Hi,
I just wonder that this info only applies to CISCO 2500 or It can apply to PIX515. I am having a simliar issue with PIX515. Although IPsec tunnel is established successfully with VPN client, I can not access any resource. looking forward to your answer. Many Thanks DJ
05-27-2003 10:52 PM
In the PIX youshould have the command:
> sysopt connection permit-ipsec
which will allow all IPsec packets in, you don't have the same issues as you do with IOS and ACL's. If you can build a tunnel but can't ping anything, check your NAT 0 command and make sure it references an access-list that permits traffic from your inside networks to your VPN pool of addresses.
Alternatively, make sure you have IP protocol 50 connectivity from client to firewall, or if you're going through a NAT device anywhere, enable the nat-traversal on the PIX in 6.3 code.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide