All you ISCW Gurus

chrisone

ilcram19-2 wrote: »

just practice this is actually pretty easy i've setup thousends of ipsec tunnels but i dont really do them anymore i rather do gre/ipsec they allow me to do more thing routing qos etc,

amen! thats all we use at work, GRE over IPSEC. I love routing EIGRP too good stuff.

burbankmarc

UPDATE

So, I was able to have them send me their ACL and their transform set:

access-list 150 permit ip 10.50.50.0 255.255.255.0 172.26.1.0 255.255.255.248
ESP-3DES-SHA

So I changed my access-list to mirror that. Yet, I'm still getting the same exact debugs.

deleting node -590478842 error FALSE reason "Informational (in) state 1"
004245: Dec 18 16:07:41.292 EST: ISAKMP[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_sad.gif[/IMG]0:2:SW:1):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
004246: Dec 18 16:07:41.296 EST: ISAKMP[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_sad.gif[/IMG]0:2:SW:1):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE 

004247: Dec 18 16:07:41.296 EST: IPSEC(key_engine): got a queue event with 1 kei messages
004248: Dec 18 16:07:41.296 EST: IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
004249: Dec 18 16:07:41.296 EST: IPSEC(key_engine_delete_sas): delete all SAs shared with peer 147.187.1.4    
004250: Dec 18 16:07:51.220 EST: ISAKMP[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_sad.gif[/IMG]0:2:SW:1): retransmitting phase 2 QM_IDLE       -1908817770 ...
004251: Dec 18 16:07:51.220 EST: ISAKMP (0:134217730): incrementing error counter on node, attempt 1 of 5: retransmit phase 2
004252: Dec 18 16:07:51.220 EST: ISAKMP (0:134217730): incrementing error counter on sa, attempt 1 of 5: retransmit phase 2

I need to get to finish the BCMSN soon so I can get to the ISCW and not feel out of my element.

burbankmarc

Well i fixed it.

I had dh 2 applied to the isakmp policy, but i didn't apply it to the crypto map. Once I applied it to the crypto map all came up.

Thanks for the help guys, also it was a good learning experience.

NightShade03

I guess it goes to show that its good to walk through these senarios for the exam. Glad to see that the debug message wasn't too far off

chrisone

yeah the key to mostly all troubleshooting is understanding the debug errors

SysAdmin4066

burbankmarc wrote: »

Well i fixed it.

I had dh 2 applied to the isakmp policy, but i didn't apply it to the crypto map. Once I applied it to the crypto map all came up.

Thanks for the help guys, also it was a good learning experience.

What do you mean? You dont apply the isakmp policy to the crypto map. What did you not apply to the crytpo map?

ilcram19-2

SysAdmin4066 wrote: »

What do you mean? You dont apply the isakmp policy to the crypto map. What did you not apply to the crytpo map?

he meant he had deffi hellman group 2 on the isakmp, but it was probably missing on the crypto map. dfs group 2

SysAdmin4066

I've never placed the dh group on the crypto map. Jason, you ever put a dh group statement directly into the crypto map?

SysAdmin4066

Apparently the set pfs crypto map command is a stand in for the group X isakmp policy command. PFS is an optional feature of IPSec. What i've always done for just an IPSec tunnel is this config;

Set the ISAKMP Policy
crypto isakmp policy 10

Set the configurations of ISAKMP Pol 10
Authentication pre-share
encryption 3des
group 2
hash sha1
lifetime 3600

Set the ISAKMP Key (for preshared key)
crypto isakmp key 0 cisco address x.x.x.x

Set IPSec transform set
crypto ipsec transform-set mytrans esp-3des esp-sha1-hmac
exit (no further configuration is necessary)

Set Crypto ACL
access-list 101 permit ip x.x.x.x x.x.x.x (source network to be encrypted and inverse mask) x.x.x.x x.x.x.x (destination network and inverse mask)

Configure the Crypto Map statement
crypto map mymap 10 ipsec-isakmp
(in crypto map configuration mode)
match address 101 (our crypto acl)
set peer x.x.x.x
set transform-set mytrans
exit (no further configuration necessary)

Now, apply the crypto map to your interface
interface s 0/0/0
crypto map mymap

Mirror this config on the other side and you're golden. So can someone tell me why you would use pfs on a site to site vpn? The only time i've used pfs is setting up ezvpn server.

ilcram19-2

i rather use named ACLs they are a lilttle more flexible

ilcram19-2

they also look cleaner and allow to have a reference point and to know where that acl belongs to by just looking and it and not searching all over my config

Extended IP access list USA-1253
10 permit ip 10.1.2.0 0.0.0.255 10.1.4.0 0.0.0.255 (215803 matches)

SysAdmin4066

I prefer named as well. I put the numbered for simplicity.

SysAdmin4066

So, PFS. Why would you use it at all for a site to site VPN?

ilcram19-2

well i dont know if you know this but by default you use DFS group 1, if you wanna increase security you can use 2 or 5.

"The default (group1) is sent if the set pfs statement does not specify a group".

so i guess depends if you want to increase security from group 1 to group 2 or group 5.

"PFS adds another level of security because if one key is ever cracked by an attacker then only the data sent with that key will be compromised. Without PFS, data sent with other keys could also be compromised"

SysAdmin4066

ilcram19-2 wrote: »

well i dont know if you know this but by default you use DFS group 1, if you wanna increase security you can use 2 or 5.

"The default (group1) is sent if the set pfs statement does not specify a group".

so i guess depends if you want to increase security from group 1 to group 2 or group 5.

"PFS adds another level of security because if one key is ever cracked by an attacker then only the data sent with that key will be compromised. Without PFS, data sent with other keys could also be compromised"

I think we're confusing PFS and IKE DH groups here. Both use the DH algorithm, but they do different things. PFS isnt a default setting, by default PFS is not used. DH Group 1 is only default FOR PFS if you do not specify a group, i.e. just inputing the statement set pfs in crypto map configuration mode. PFS is optional, it is not required for IPSec operation.

I'm assuming the other side was using it and his side was not, which is why the ipsec phase of the tunnel wouldnt complete (phase 2) but I'm trying to figure out why use it? Placing a group statement under the isakmp policy configuration mode would suffice for IKE DH key strength, and is all that is required to build a tunnel. PFS is not. I figured maybe he has some insight into PFS that I didnt, or that I overlooked, as to why use it.

This is another example of why it is imperative to have both sides of a VPN when troubleshooting. You might as well be reading tea leaves, because it could be literally anything. And the debug didnt seem to point to any particular problem, besides a mismatch in the configs.

ilcram19-2

SysAdmin4066 wrote: »

I think we're confusing PFS and IKE DH groups here. Both use the DH algorithm, but they do different things. PFS isnt a default setting, by default PFS is not used. DH Group 1 is only default FOR PFS if you do not specify a group, i.e. just inputing the statement set pfs in crypto map configuration mode. PFS is optional, it is not required for IPSec operation.

I'm assuming the other side was using it and his side was not, which is why the ipsec phase of the tunnel wouldnt complete (phase 2) but I'm trying to figure out why use it? Placing a group statement under the isakmp policy configuration mode would suffice for IKE DH key strength, and is all that is required to build a tunnel. PFS is not. I figured maybe he has some insight into PFS that I didnt, or that I overlooked, as to why use it.

This is another example of why it is imperative to have both sides of a VPN when troubleshooting. You might as well be reading tea leaves, because it could be literally anything. And the debug didnt seem to point to any particular problem, besides a mismatch in the configs.

again PFS group 1 is the default for the crypto map the information that i provide you was from the cisco website


"The default (group1) is sent if the "SET PFS" statement does not specify a group".


that what you were asking why would you use PFS


here is the whole text



The default (group1) is sent if the set pfs statement does not specify a group. If the peer initiates the negotiation and the local configuration specifies PFS, the remote peer must perform a PFS exchange or the negotiation will fail. If the local configuration does not specify a group, a default of group1 will be assumed, and an offer of either group1, group2, or group5 will be accepted. If the local configuration specifies group2 or group5, that group must be part of the offer from the peer or the negotiation will fail. If the local configuration does not specify PFS, it will accept any offer of PFS from the peer.

IKE is another story and it does have it own defaults.

ilcram19-2

also

PFS—perfect forward secrecy. PFS ensures that a given key of an IPSec security association was not derived from any other secret (like some other keys). In other words, if someone were to break a key, PFS ensures that the attacker would not be able to derive any other key. If PFS were not enabled, someone could hypothetically break the IKE SA secret key, copy all the IPSec-protected data, and then use knowledge of the IKE SA secret to compromise the IPSec SAs set up by this IKE SA. With PFS, breaking IKE would not give an attacker immediate access to IPSec. The attacker would have to break each IPSec SA individually. """"""Cisco IOS IPSec implementation uses PFS group 1 (DH 768 bit) by default""""""".

ilcram19-2

also

To specify that IPSec should not request PFS, use the no form of the command.
no set pfs

SysAdmin4066

I get it, PFS adds another layer of security to the IPSec SA. It also adds more overhead/processing costs. It's not a standard, default VPN tunnel setup though right? PFS is not enabled by default and is not necessary to enable an IPSec VPN tunnel, correct? So what I'm asking of Marc is why are they using PFS? I guess I wasnt clear on that. But we agree that PFS is not a default setting right? You dont need to input the no part of the command unless you've already input the set pfs statement, it is already off by default, hence the optional status. Am I wrong here?

ilcram19-2

SysAdmin4066 wrote: »

I get it, PFS adds another layer of security to the IPSec SA. It also adds more overhead/processing costs. It's not a standard, default VPN tunnel setup though right? PFS is not enabled by default and is not necessary to enable an IPSec VPN tunnel, correct? So what I'm asking of Marc is why are they using PFS? I guess I wasnt clear on that. But we agree that PFS is not a default setting right? You dont need to input the no part of the command unless you've already input the set pfs statement, it is already off by default, hence the optional status. Am I wrong here?

Of course everything vpn releated adds over head, but depens im pretty sure he is aware of that is an optional thing, as well as is uptional if you want to use transport or tunnel in you ipsec trans set, you will be saving 20 bytes of over head is u use transport but tunnel is more secure. Alot of companies that i've been working with required group 5, aes 128 and pfs group 2, so that does add alot of over head, but alot of the tunnels arent change so you need make sure that the security will cover you aleast for the next 2-5 years,i dont thing they will ever brake AES 128 but u never know, better be safe than sorry.

SysAdmin4066

Got ya, I just wanted to know if he knew why they were using PFS. Unfortunately, overhead is a huge problem. Doing the ONT, i'm going over bandwidth calculations for VoIP and man, that is just crazy. More often than not, the overhead, IP, UDP, RTP headers, the codecs, etc are more than the voice payload lol. You can have 160k of overhead for a 20k payload size

burbankmarc

I agree, the debugs were pretty vague, all it told me is the phase 1 was cool, but phase 2 wasn't happening.

With all the different tunnel options it really became a trial and error endeavour. Unfortunately the company we're peering with didn't want to give me ssh access to their pix, but then again I don't really blame them.

NightShade03

burbankmarc wrote: »

Unfortunately the company we're peering with didn't want to give me ssh access to their pix, but then again I don't really blame them.

Why not...its not like there are any security concerns with that

abdulwart

It was cool discussion guys. I swear to god I did not understand a word of it, however, I know it is something I am coming to in the near future and I feel that I am encouraged to study harder to reach your level guys.

You are awesome guys

SysAdmin4066

No worries Abdulwart, the ISCW will get you at least familiar with the topics we discussed. The rest can be had by doing your own research and finding out about all of the caveats and extra features. The basics take you a very long way though. Good luck on the BSCI, its a bear, but it's doable.