RE: VPN troubles [7:10714]
Hi You might have got the solution by now .. if not then read .. When the packet leaves the router it will have the source address of its outgoing interface in the IP packet. Now this address is not part of the tunnel so it will be routed normally. You need to have the router send the packets with an address which is part of traffic permitted in the tunnel acl. For your specific tacacs application, on 2600 enter the command ip tacacs source-interface This interface can be the LAN side interface if its subnet is in the tunnel or you can create a loopback with such an address. You can find a similar command on PIX if you are trying to authenticate PIX across VPN. Hope that helps .. Majid Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=48974t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10813t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10819t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10 match ip address 130 ! snmp-server engineID local 000902309468D480 snmp-server community RO snmp-server community RW ! line con 0 exec-timeout 30 0 transport input none line aux 0 line vty 0 4 password 7 login ! ntp clock-period 17180260 ntp server 192.168.103.242 prefer ! end - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 10:14 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop beca
Re: VPN troubles [7:10714]
can't resist Hey Michael, that's some CCIE# you go there :-) Kevin Wigle - Original Message - From: Yonkerbonk To: Sent: Tuesday, July 03, 2001 11:30 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10828t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
I reread the problem you were having. I missed it before. You are trying to ping an address on the other side of the VPN that is in the same range as on your local LAN? That's where you're running into a problem. You're trying to bridge across the tunnel. If you want that, you need to specify that. Otherwise, you will need to do NAT to translate the addresses - destination or source. The PIX has an alias command that double NATs for this very problem. Never tried it with VPN tunnel tho, but I guess it should be the same. Michael Le, CCIE #6811 --- Allen May wrote: Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10 match ip address 130 ! snmp-server engineID local 000902309468D480 snmp-server community RO snmp-server community RW ! line con 0 exec-timeout 30 0 transport input none line aux 0 line vty 0 4 password 7 login ! ntp clock-period 17180260 ntp server 192.168.103.242 prefer ! end - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 10:14 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side
Re: VPN troubles [7:10714]
That's what I get for not creating a signature. Michael --- Kevin Wigle wrote: can't resist Hey Michael, that's some CCIE# you go there :-) Kevin Wigle - Original Message - From: Yonkerbonk To: Sent: Tuesday, July 03, 2001 11:30 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10870t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
Actually it's not in the same range. The config I sent was from a 2600 on 10.43.2.0/24 and the destination on the other end of the tunnel is 10.43.1.0/24. It is set up to only allow IP's originating from 10.43.2.0/24 to go through the tunnel (vice-versa on other end). Everything else gets routed out to the internet nat'd. NAT does not work with IPSec tunnels according to all the documents I found on cisco.com. The whole problem is that it won't use the 10.43.2.1 interface as the source IP when I try to get across the tunnel from the router. Thanks alot for the help...I do appreciate it. Any other ideas? I'm about to give up use the work-around of sending TACACS+ authentication requests over the internet via a real IP address. That will just mean I have to add another access-list for source IP's allowed into the TACACS+ box. More work but it would be do-able. Allen - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 1:40 PM Subject: Re: VPN troubles [7:10714] I reread the problem you were having. I missed it before. You are trying to ping an address on the other side of the VPN that is in the same range as on your local LAN? That's where you're running into a problem. You're trying to bridge across the tunnel. If you want that, you need to specify that. Otherwise, you will need to do NAT to translate the addresses - destination or source. The PIX has an alias command that double NATs for this very problem. Never tried it with VPN tunnel tho, but I guess it should be the same. Michael Le, CCIE #6811 --- Allen May wrote: Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10 match ip address 130 ! snmp-server engineID local 000902309468D480 snmp-server community RO snmp-server community RW ! line con 0 exec-timeout 30 0 transport input none line aux 0 line vty 0 4 password 7 login ! ntp clock-period 17180260 ntp server 192.168.103.242 prefer ! end - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 10:14 AM Subject: Re
RE: VPN troubles [7:10714]
which leads me to wonder - when the numbers reach , does it roll over to ? :- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Wigle Sent: Tuesday, July 03, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: Re: VPN troubles [7:10714] can't resist Hey Michael, that's some CCIE# you go there :-) Kevin Wigle - Original Message - From: Yonkerbonk To: Sent: Tuesday, July 03, 2001 11:30 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10881t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VPN troubles [7:10714]
you're a router guy. signatures are sys admin problems ;- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Yonkerbonk Sent: Tuesday, July 03, 2001 11:58 AM To: [EMAIL PROTECTED] Subject: Re: VPN troubles [7:10714] That's what I get for not creating a signature. Michael --- Kevin Wigle wrote: can't resist Hey Michael, that's some CCIE# you go there :-) Kevin Wigle - Original Message - From: Yonkerbonk To: Sent: Tuesday, July 03, 2001 11:30 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10882t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: VPN troubles [7:10714]
c'mon Chuck you know that the first 1024 are reserved. It will roll over to 1025 again. Can you think of a faster way to get people to re-certify? :-) -Original Message- From: Chuck Larrieu [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 03, 2001 2:23 PM To: [EMAIL PROTECTED] Subject: RE: VPN troubles [7:10714] which leads me to wonder - when the numbers reach , does it roll over to ? :- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kevin Wigle Sent: Tuesday, July 03, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: Re: VPN troubles [7:10714] can't resist Hey Michael, that's some CCIE# you go there :-) Kevin Wigle - Original Message - From: Yonkerbonk To: Sent: Tuesday, July 03, 2001 11:30 AM Subject: Re: VPN troubles [7:10714] What you need to test with is do an extended ping. Type in ping ip and then enter. And then follow the prompts after that. It gives you the choice of picking which ip address the router will use as the source. By default is uses the interface the packet leaves from. Michael Le, CCIE #681 --- Allen May wrote: OK I'll get the configs forward in a bit. But for now...the inside interface has an IP on that subnet. What would it take to get it to work from the router itself? It's got an outside IP going to the ISP and an inside IP for a 10.43.2.0/24 network with a secondary IP on the inside interface of 10.43.2.1. I guess what I'm trying to say is...how DO you make it work then? ;) Allen - Original Message - From: G30RG3 To: Sent: Monday, July 02, 2001 7:53 PM Subject: Re: VPN troubles [7:10714] The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen [EMAIL PROTECTED] __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10886t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
The only thing I can think of is packets originating from the router normally don't get passed through access-lists. But I remember being able to pass router-originated packets through my tunnel just fine, so I'm not sure what the rules for VPNs are. Sorry. Michael --- Allen May wrote: Actually it's not in the same range. The config I sent was from a 2600 on 10.43.2.0/24 and the destination on the other end of the tunnel is 10.43.1.0/24. It is set up to only allow IP's originating from 10.43.2.0/24 to go through the tunnel (vice-versa on other end). Everything else gets routed out to the internet nat'd. NAT does not work with IPSec tunnels according to all the documents I found on cisco.com. The whole problem is that it won't use the 10.43.2.1 interface as the source IP when I try to get across the tunnel from the router. Thanks alot for the help...I do appreciate it. Any other ideas? I'm about to give up use the work-around of sending TACACS+ authentication requests over the internet via a real IP address. That will just mean I have to add another access-list for source IP's allowed into the TACACS+ box. More work but it would be do-able. Allen - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 1:40 PM Subject: Re: VPN troubles [7:10714] I reread the problem you were having. I missed it before. You are trying to ping an address on the other side of the VPN that is in the same range as on your local LAN? That's where you're running into a problem. You're trying to bridge across the tunnel. If you want that, you need to specify that. Otherwise, you will need to do NAT to translate the addresses - destination or source. The PIX has an alias command that double NATs for this very problem. Never tried it with VPN tunnel tho, but I guess it should be the same. Michael Le, CCIE #6811 --- Allen May wrote: Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10
Re: VPN troubles [7:10714]
The only thing I can think of is packets originating from the router normally don't get passed through access-lists. But I remember being able to pass router-originated packets through my tunnel just fine, so I'm not sure what the rules for VPNs are. Sorry. Michael --- Allen May wrote: Actually it's not in the same range. The config I sent was from a 2600 on 10.43.2.0/24 and the destination on the other end of the tunnel is 10.43.1.0/24. It is set up to only allow IP's originating from 10.43.2.0/24 to go through the tunnel (vice-versa on other end). Everything else gets routed out to the internet nat'd. NAT does not work with IPSec tunnels according to all the documents I found on cisco.com. The whole problem is that it won't use the 10.43.2.1 interface as the source IP when I try to get across the tunnel from the router. Thanks alot for the help...I do appreciate it. Any other ideas? I'm about to give up use the work-around of sending TACACS+ authentication requests over the internet via a real IP address. That will just mean I have to add another access-list for source IP's allowed into the TACACS+ box. More work but it would be do-able. Allen - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 1:40 PM Subject: Re: VPN troubles [7:10714] I reread the problem you were having. I missed it before. You are trying to ping an address on the other side of the VPN that is in the same range as on your local LAN? That's where you're running into a problem. You're trying to bridge across the tunnel. If you want that, you need to specify that. Otherwise, you will need to do NAT to translate the addresses - destination or source. The PIX has an alias command that double NATs for this very problem. Never tried it with VPN tunnel tho, but I guess it should be the same. Michael Le, CCIE #6811 --- Allen May wrote: Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10
Re: VPN troubles [7:10714]
The only thing I can think of is packets originating from the router normally don't get passed through access-lists. But I remember being able to pass router-originated packets through my tunnel just fine, so I'm not sure what the rules for VPNs are. Sorry. Michael --- Allen May wrote: Actually it's not in the same range. The config I sent was from a 2600 on 10.43.2.0/24 and the destination on the other end of the tunnel is 10.43.1.0/24. It is set up to only allow IP's originating from 10.43.2.0/24 to go through the tunnel (vice-versa on other end). Everything else gets routed out to the internet nat'd. NAT does not work with IPSec tunnels according to all the documents I found on cisco.com. The whole problem is that it won't use the 10.43.2.1 interface as the source IP when I try to get across the tunnel from the router. Thanks alot for the help...I do appreciate it. Any other ideas? I'm about to give up use the work-around of sending TACACS+ authentication requests over the internet via a real IP address. That will just mean I have to add another access-list for source IP's allowed into the TACACS+ box. More work but it would be do-able. Allen - Original Message - From: Yonkerbonk To: Allen May ; Sent: Tuesday, July 03, 2001 1:40 PM Subject: Re: VPN troubles [7:10714] I reread the problem you were having. I missed it before. You are trying to ping an address on the other side of the VPN that is in the same range as on your local LAN? That's where you're running into a problem. You're trying to bridge across the tunnel. If you want that, you need to specify that. Otherwise, you will need to do NAT to translate the addresses - destination or source. The PIX has an alias command that double NATs for this very problem. Never tried it with VPN tunnel tho, but I guess it should be the same. Michael Le, CCIE #6811 --- Allen May wrote: Doesn't seem to work with 12.0(5). Here's the config. FastEthernet0/0 secondary IP is in the range capable of going over the VPN. When the router tries to ping over the VPN it just uses the default gateway out to the internet. I have a workaround to just give the TACACS+ box an internet address but it's bugging me that this won't work the way it was originally planned. Using 2646 out of 29688 bytes ! version 12.0 service timestamps debug datetime localtime service timestamps log datetime localtime service password-encryption ! hostname MSI-2621 ! logging buffered 4096 debugging no logging console enable password 7 * ! ! ! ! ! clock timezone CST -6 clock summer-time CST recurring ip subnet-zero ip name-server 209.113.31.100 ! ip audit notify log ip audit po max-events 100 ! ! crypto isakmp policy 11 hash md5 authentication pre-share crypto isakmp key * address 207.x.y.70 ! ! crypto ipsec transform-set msiset esp-des esp-md5-hmac ! ! crypto map nolan 11 ipsec-isakmp set peer 207.x.y.70 set transform-set msiset match address 120 ! ! ! process-max-time 200 ! interface FastEthernet0/0 description MSI-LAN Austin ip address 10.43.2.1 255.255.255.0 secondary ip address 192.168.103.1 255.255.255.0 no ip directed-broadcast ip nat inside ! interface Serial0/0 description MSI-Austin to Insync-Houston T1 (Internet) ip address 207.x.y.22 255.255.255.252 no ip directed-broadcast ip nat outside no ip route-cache no ip mroute-cache crypto map nolan ! interface FastEthernet0/1 description MSI DMZ LAN ip address 207.x.y.129 255.255.255.224 no ip directed-broadcast ! interface Serial0/1 description MSI-Austin to Microspace-Raleigh T1 ip address 192.168.254.10 255.255.255.252 no ip directed-broadcast service-module t1 clock source internal ! router ospf 100 redistribute connected subnets redistribute static subnets network 192.168.103.0 0.0.0.255 area 0 network 192.168.254.8 0.0.0.3 area 0 network 207.x.y.160 0.0.0.31 area 0 ! ip nat pool MSI-LAN 207.x.y.129 207.x.y.148 netmask 255.255.255.224 ip nat inside source route-map nonat pool MSI-LAN overload ip classless ip route 0.0.0.0 0.0.0.0 207.170.95.21 ip route 10.0.0.0 255.0.0.0 10.43.1.1 permanent ip route 207.x.y.120 255.255.255.248 207.x.y.14 ip route 207.x.y.128 255.255.255.224 207.x.y.14 no ip http server ! access-list 1 permit 192.168.103.0 0.0.0.255 access-list 120 permit ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 deny ip 10.43.2.0 0.0.0.255 10.43.1.0 0.0.0.255 access-list 130 permit ip 10.43.2.0 0.0.0.255 any access-list 130 permit ip 192.168.103.0 0.0.0.255 any access-list 198 permit icmp any any route-map nonat permit 10
VPN troubles [7:10714]
I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10714t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: VPN troubles [7:10714]
The reason you cant ping from the router itself is that when you specified what traffic to encrypt and send to the tunnel you only specified the subnets behind the firewall and router. If you try and ping the other side it will not go through the tunnel because it is not a match on the access-list. That is one of the reasons. I cant say that is the only reason cuz I don't know what your configs look like. Hope that helps George, Head Janitor, CCNA CCDA Cisco Systems Allen May wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I have an IPSec tunnel set up between PIX and a 2600 and it works perfectly for clients end-to-end. However, I can't ping across the VPN from pix or router. I suspect a routing issue. When I try to add a route to tell it anything going to the other end should use that IP on that interface, it gives an error saying invalid hop because it's on that router. Any ideas? A little info: Remote network has 10.43.2.0/24 but gateway is a secondary IP on the internal FastEthernet interface of a 2600. Central network is 10.43.1.0/24 on a PIX 515. Future networks will be on the 10.x.y.z network centralize to the PIX rack. The problem I'm trying to solve is making the remote routers authenticate over the VPN to TACACS+ for the enable password. If I can't ping the box because it's trying to bo out the default route, it won't work. Allen Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=10731t=10714 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
