[c-nsp] debugging and tracing on IP-Sec tunnel
Hi Folks I need some advise regarding trace and debug on a tunnel with IPSec. We are using a provider to some kind off health service, these servers can be reached via a tunnel interface in our network and vise versa. My problem is that one server is out off reach on http traffic but not on ssh. If I deploy an access-list on the tunnel interface, I can see that the http-traffic is being forwarded via the tunnel interface. So how can I be sure that the IP-Sec interface also is forwarding the http traffic and not just ssh. crypto isakmp policy 10 encr 3des hash md5 authentication pre-share lifetime 43200 crypto isakmp key Klipklapklop4433saksen address x ! crypto ipsec security-association lifetime seconds 43200 ! crypto ipsec transform-set strong esp-3des esp-md5-hmac ! crypto map MEDMAP 2 ipsec-isakmp description nja - medcom set peer xxx set transform-set strong match address krypt-medcom interface Tunnel1 description GRE interface ip address xxx.xxx.xxx.xxx 255.255.255.252 ip mtu 1300 ip nat outside keepalive 10 3 tunnel source FastEthernet0/0 tunnel destination xxx.xxx.xxx.xxx ! interface FastEthernet0/0 description Outside - Internetrouter ip address xxx.xxx.xxx.xxx 255.255.255.128 speed 100 full-duplex crypto map MEDMAP ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Can an AS5350 route ISDN calls to ISDN?
Andreas Sikkema wrote: How do I add 310 as a prefix to the calls from port 3/3 so that dialpeer 100 does not match and calls go to dialpeer 12 (or something functionally similar)? To add translations based on a specific physical port, you have to add the translation profile to the voice-port for 3/3, so that the translation can happen before any dial-peer matching is done (that's the order of evaluation). Example: voice translation-rule 2 rule 1 /^\(.+\)/ /05500\1/ ! ! voice translation-profile FAX-TRANSLATIONS translate called 2 ! ... ! voice-port 4/1:D translation-profile incoming FAX-TRANSLATIONS no comfort-noise bearer-cap 3100Hz ! ... ! dial-peer voice 803 voip description FAX DIDs destination-pattern 05500T session protocol sipv2 session target ipv4:XXX.YYY.ZZZ.AAA session transport udp dtmf-relay rtp-nte codec g711ulaw fax rate 14400 bytes 255 fax protocol pass-through g711ulaw no vad -- This example stamps a prefix of 05500 on all calls that come in on T1 4/1, and then there is a dial peer that matches 05500 + anything. In this case, it's a VoIP peer, but it doesn't have to be. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] debugging and tracing on IP-Sec tunnel
On Fri, 2008-08-01 at 07:32 +0200, Arne Larsen wrote: I need some advise regarding trace and debug on a tunnel with IPSec. We are using a provider to some kind off health service, these servers can be reached via a tunnel interface in our network and vise versa. My problem is that one server is out off reach on http traffic but not on ssh. If I deploy an access-list on the tunnel interface, I can see that the http-traffic is being forwarded via the tunnel interface. So how can I be sure that the IP-Sec interface also is forwarding the http traffic and not just ssh. You could place a sniffer on the outside to look for ESP packets. If there's a time window with no or little other traffic, you could be fairly certain that some generated HTTP traffic is what you see on the outside. An access-list in Fa0/0 should also work. It could be the same as you use for encrypting (krypt-medcom), which I presume allows GRE traffic from your end to the other end. Both are limited by the fact that the traffic is now encrypted, so it's harder to tell if what you see is really is what you expect. Of course there could be other problems: The other end of the tunnel not accepting the traffic (this specific peer usually sends unreachables though) or maybe PMTUd problems. If a simple telnet towards port 80 is working, but downloading pages isn't, adjust-mss might help. (We use ip tcp adjust-mss 1355 on our tunnel towards this provider.) This is less probable if you have two similar servers working, but they might be behind different tunnels themselves in the other end. Mail me off list if you'd like me to test things from our end. :-) Regards, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] DPD dead peer detection
Hi, probably someone can help me to answer the following question. I have a VPN router (Router_a) with 2 interfaces connected to 2 ISP's with 2 IP's and I have a homeoffice with a small VPN router (Router_b) connected to one ISP with one interface and one IP. Now I want to use DPD to check which route to use to connect from Router_b to Router_a. ISP1 is the default, ISP2 is backup. As far as I understand DPD is a keepalive to check if a peer is up and switches between peers and does not do anything with the routing. So it checks only if the key exchange works and peer is established within same tunnel. If it is like that, I can not use DPD to solve my problem and should use track and ip sla monitor. Best Stefan -- Stefan Hegger Internet System Engineer Lycos Europe GmbH Carl-Bertelsmann Str. 29 Postfach 315 33312 Gütersloh Phone: Tel: +49 5241 8071 334 Fax: +49 5241 80671 334 Mobile: +49 170 1892720 Sitz der Gesellschaft: Gütersloh Amtsgericht Gütersloh, HRB 2157 Geschäftsführer: Christoph Mohn http://www.lycos-europe.com/L/A/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Filtering telnet without ACL
Hello, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? Regards, Joost ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow / 3560 platform
David Curran wrote: Touche. I was speaking of the smaller catalyst platforms. However I'm not sure its fair to real routers to call the Supervisors route processors. That's like calling a Yugo a race car. Sure, you COULD race it... Look at the specs of the RSP-720. It would be a lot faster at software forwarding than all of the devices mentioned earlier. (it'd probably be similar speed to the NPE-G2, I guess) The issue is that the switch architecture makes it very hard to accurately track and record the information needed for netflow. This information is stored in TCAM, which is already scarce enough on those platforms! adam. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Filtering telnet without ACL
On Fri, 01 Aug 2008, Joost greene wrote: Hello, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? Regards, Joost ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Route map... ip access-list extended NO_TELNET deny tcp any any eq 23 ! route-map BLOCK_TELNET 10 match ip address NO_TELNET set interface Null 0 ! ip local policy route-map BLOCK_TELNET -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) CEH/CNDA, CHFI Experience hath shewn, that even under the best forms (of government) those entrusted with power have, in time, and by slow operations, perverted it into tyranny. Thomas Jefferson wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x3AC173DB ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Filtering telnet without ACL
On (2008-08-01 15:14 +0200), Joost greene wrote: Hey, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? I assume challenge was set, because asker knows how to do it. If not, then I think challenge should be, how to make router output PONIES. Anyhow, I think CoPP, rACL and policy-route would break the 'no acl' definition and wouldn't be acceptable solution. I think what would fit the rule, is MPLS LSR where you'd only have route back to couple management hosts and others couldn't telnet to the box, simply because box doesn't have route to them. Of course everyone in your IGP could telnet to the box also. -- ++ytti ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Filtering telnet without ACL
On Fri, August 1, 2008 4:14 pm, Joost greene wrote: Hello, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? Regards, Joost ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Well if we assume that this is an ethernet network and the hosts are within our broadcast domain I think you can use MQC = NBAR something like: class-map match-all PERMIT_TELNET match protocol telnet match class-map PERMIT_TELNET_HOSTS exit class-map match-any PERMIT_TELNET_HOSTS match source-address mac xxx.xxx.xxx match source-address mac yyy.yyy.yyy exit class-map DENY_TELNET match protocol telnet exit policy-map IN_FE0/0 class PERMIT_TELNET bandwidth remaining percent 100 class DENY_TELNET drop int fastether0/0 service-policy input IN_FE0/0 -- WWell by Iassen Anadoliev ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow / 3560 platform
Agreed, and not to beat a dead horse, but there are mechanisms to send full packets to the processor and still circulate packets via the switch path for forwarding. My point is that a switch that has a reported 720G throughput most likely does not have the processor to do netflow on all of that. That was my point about comparing a switch to a router.OK, I promise, I'm done ;) From: Adam Armstrong [EMAIL PROTECTED] Date: Fri, 01 Aug 2008 14:04:50 +0100 To: David Curran [EMAIL PROTECTED], cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Netflow / 3560 platform David Curran wrote: Touche. I was speaking of the smaller catalyst platforms. However I'm not sure its fair to real routers to call the Supervisors route processors. That's like calling a Yugo a race car. Sure, you COULD race it... Look at the specs of the RSP-720. It would be a lot faster at software forwarding than all of the devices mentioned earlier. (it'd probably be similar speed to the NPE-G2, I guess) The issue is that the switch architecture makes it very hard to accurately track and record the information needed for netflow. This information is stored in TCAM, which is already scarce enough on those platforms! adam. This email and any attachments (Message) may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Filtering telnet without ACL
I like the answer from Iassen, while it does leave some question as to where the source packet comes from though as he has assumed local broadcast segment, I guess you could add to your answer should the packet be from beyond a layer 3 boundary then the 2 hosts can be requested to mark traffic (or even a different router along the path mark it) to match in your class map on this router, that way you still avoid ACL's but meet the question requirements, that is a stupid way of doing it though as it's not very secure should someone learn the magic tos bit to use to get telnet access :) - Original Message - From: Iassen Anadoliev [EMAIL PROTECTED] To: Joost greene [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Saturday, August 02, 2008 12:08 AM Subject: Re: [c-nsp] Filtering telnet without ACL On Fri, August 1, 2008 4:14 pm, Joost greene wrote: Hello, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? Regards, Joost ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Well if we assume that this is an ethernet network and the hosts are within our broadcast domain I think you can use MQC = NBAR something like: class-map match-all PERMIT_TELNET match protocol telnet match class-map PERMIT_TELNET_HOSTS exit class-map match-any PERMIT_TELNET_HOSTS match source-address mac xxx.xxx.xxx match source-address mac yyy.yyy.yyy exit class-map DENY_TELNET match protocol telnet exit policy-map IN_FE0/0 class PERMIT_TELNET bandwidth remaining percent 100 class DENY_TELNET drop int fastether0/0 service-policy input IN_FE0/0 -- WWell by Iassen Anadoliev ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Filtering telnet without ACL
I like the answer from Iassen, while it does leave some question as to where the source packet comes from though as he has assumed local broadcast segment, I guess you could add to your answer should the packet be from beyond a layer 3 boundary then the 2 hosts can be requested to mark traffic (or even a different router along the path mark it) to match in your class map on this router, that way you still avoid ACL's but meet the question requirements, that is a stupid way of doing it though as it's not very secure should someone learn the magic tos bit to use to get telnet access :) - Original Message - From: Iassen Anadoliev [EMAIL PROTECTED] To: Joost greene [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net Sent: Saturday, August 02, 2008 12:08 AM Subject: Re: [c-nsp] Filtering telnet without ACL On Fri, August 1, 2008 4:14 pm, Joost greene wrote: Hello, Someone challenged me with a question on how i can filter telnet access to one router from all hosts except two of them WITHOUT using access-lists or access-line under the VTY? any ideas? Regards, Joost ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ Well if we assume that this is an ethernet network and the hosts are within our broadcast domain I think you can use MQC = NBAR something like: class-map match-all PERMIT_TELNET match protocol telnet match class-map PERMIT_TELNET_HOSTS exit class-map match-any PERMIT_TELNET_HOSTS match source-address mac xxx.xxx.xxx match source-address mac yyy.yyy.yyy exit class-map DENY_TELNET match protocol telnet exit policy-map IN_FE0/0 class PERMIT_TELNET bandwidth remaining percent 100 class DENY_TELNET drop int fastether0/0 service-policy input IN_FE0/0 -- WWell by Iassen Anadoliev ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow / 3560 platform
Thanks for your responses. I thought it was Cisco's evil plan to make customers purchase the more expensive 650x line of switches for Netflow :-) /b On Fri, Aug 1, 2008 at 8:38 AM, David Curran [EMAIL PROTECTED] wrote: Agreed, and not to beat a dead horse, but there are mechanisms to send full packets to the processor and still circulate packets via the switch path for forwarding. My point is that a switch that has a reported 720G throughput most likely does not have the processor to do netflow on all of that. That was my point about comparing a switch to a router.OK, I promise, I'm done ;) From: Adam Armstrong [EMAIL PROTECTED] Date: Fri, 01 Aug 2008 14:04:50 +0100 To: David Curran [EMAIL PROTECTED], cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Netflow / 3560 platform David Curran wrote: Touche. I was speaking of the smaller catalyst platforms. However I'm not sure its fair to real routers to call the Supervisors route processors. That's like calling a Yugo a race car. Sure, you COULD race it... Look at the specs of the RSP-720. It would be a lot faster at software forwarding than all of the devices mentioned earlier. (it'd probably be similar speed to the NPE-G2, I guess) The issue is that the switch architecture makes it very hard to accurately track and record the information needed for netflow. This information is stored in TCAM, which is already scarce enough on those platforms! adam. This email and any attachments (Message) may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
