×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Route-map not sending traffic over vpn.

Unanswered Question
Jan 31st, 2014
User Badges:

I'm trying to route all web traffic over a site to site ipsec vpn.  The vpn is up and running with no issue. The issue I've been struggling with is that I have a route-map statement that is seeing the correct traffic but for some reason its not being flagged by the cryto map statement. Which means the web traffic is heading out my default route and not over the vpn.


I think I'm close but I must be missing something.  For the acl 155 statement I"ve also tried any any eq web.   I can ping the 192.168.10.1 address from the router only if i source it from the fa0/0 interface.  I can ping it from all machiens on then 192.168.30.0/24 network.   


My question is what is wrong with my route-map statment that is keeping me from pushing web traffic out the vpn.


Thank you  ( obviously 1.1.1.1 and 2.2.2.2 are not the real ip's )


version 12.4

service timestamps debug uptime

service timestamps log datetime

service password-encryption

!

hostname Hex-2811

!

boot-start-marker

boot system flash c2800nm-advsecurityk9-mz.124-24.T5.bin

boot-end-marker

!

no logging buffered



!

aaa new-model

!

!

!

aaa session-id common

clock timezone EST -5

clock summer-time EDT recurring

no ip source-route

!

!

ip cef

!

!

no ip bootp server

ip domain name hexhome.int

ip name-server 192.168.30.8

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

!

ipv6 unicast-routing

!

!

archive

log config

  hidekeys

!

!

ip ssh version 2

!

class-map match-all test

  description For VOIP traffic

!        

!

!

crypto isakmp policy 1

encr aes 192

authentication pre-share

group 2

lifetime 43200

crypto isakmp key ********* address 2.2.2.2

!

!

crypto ipsec transform-set IOFSET2 esp-aes 192 esp-sha-hmac

!

crypto map IOFVPN 1 ipsec-isakmp

description IoM

set peer 2.2.2.2

set transform-set IOFSET2

match address 154

reverse-route static

!

!

!

!

interface FastEthernet0/0

description Internal 192 Network

ip address 192.168.30.1 255.255.255.0

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

duplex full

speed 100

!

interface FastEthernet0/1

ip address dhcp

ip access-group 112 in

no ip redirects

no ip unreachables

ip accounting access-violations

ip nbar protocol-discovery

ip nat outside

ip virtual-reassembly

no ip route-cache cef

ip policy route-map VPN_WEB

no ip mroute-cache

duplex auto

speed auto

no cdp enable

no mop enabled

crypto map IOFVPN



ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 1.1.1.1

!

ip flow-export source FastEthernet0/0

ip flow-export version 5

ip flow-export destination 192.168.30.45 3001

!

no ip http server

ip http access-class 23

ip http authentication local

no ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

ip nat inside source static tcp 192.168.30.60 443 interface FastEthernet0/1 443

ip nat inside source static tcp 192.168.30.20 21 interface FastEthernet0/1 21

ip nat inside source route-map POLICY-NAT interface FastEthernet0/1 overload

ip nat inside source static tcp 192.168.30.13 80 interface FastEthernet0/1 80

ip nat inside source static tcp 192.168.30.25 44394 interface FastEthernet0/1 44394

ip nat inside source static tcp 192.168.30.13 22 interface FastEthernet0/1 22

ip nat inside source static tcp 192.168.30.12 32400 interface FastEthernet0/1 32400

ip nat inside source static udp 192.168.30.12 32400 interface FastEthernet0/1 32400

ip nat inside source static udp 192.168.30.25 44394 interface FastEthernet0/1 44394

ip nat inside source static tcp 192.168.30.105 5901 interface FastEthernet0/1 5901

ip nat inside source static tcp 192.168.30.200 9443 interface FastEthernet0/1 9443

!

ip access-list extended NAT

deny   ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

permit ip any any

!

access-list 112 remark Explicit accept and deny

access-list 112 deny   udp any any eq snmp

access-list 112 deny   ip host 50.17.67.227 any

access-list 112 deny   ip host 1.93.27.33 any

access-list 112 deny   tcp any any eq telnet

access-list 112 permit tcp host 37.235.50.117 any eq ftp log

access-list 112 permit tcp host 5.255.80.84 any eq ftp log

access-list 112 permit tcp host 66.228.62.226 any eq ftp log

access-list 112 permit tcp host 72.25.5.126 any eq 5901 log

access-list 112 permit tcp host 72.25.5.126 any eq 11111 log

access-list 112 permit tcp host 72.25.5.126 any eq 8000 log

access-list 112 deny   tcp any any eq ftp log

access-list 112 deny   tcp any any eq 3389 log

access-list 112 deny   tcp any any eq 5901 log

access-list 112 deny   tcp any any eq 11111

access-list 112 deny   tcp any any eq 8000

access-list 112 permit ip any any

access-list 154 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 155 permit tcp 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

snmp-server community public RO

no cdp run

!

route-map VPN_WEB permit 1

match ip address 155

set ip next-hop 192.168.10.1

!

route-map POLICY-NAT permit 10

match ip address NAT

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Bradfield Fri, 01/31/2014 - 20:19
User Badges:
  • Silver, 250 points or more

Shouldn't the " ip policy route-map VPN_WEB " statement be on the inside interface fa0/0?

TheEditor Sat, 02/01/2014 - 01:50
User Badges:

I tried that.  Same thing.  I'm verifying by doing a show crypto ipsec sa and the counters don't increase. If in a browser I go to http://2.2.2.2 it works, I get an apache page and the encaps/decaps go up.  All regular web traffic still goes straight out to the web skipping the vpn altogether.

blau grana Sat, 02/01/2014 - 02:09
User Badges:
  • Gold, 750 points or more

Hi Bruce,


I think policy routing is not necessary at all, try to remove "ip policy route-map VPN_WEB".


Best Regards

Please rate all helpful posts and close solved questions

TheEditor Sat, 02/01/2014 - 02:27
User Badges:

Now I'm totally lost.   I removed it and as expected web traffic is not passing through the vpn. 


If you remove that policy then how does the router know what to do with port 80 traffic?  Something has to tell it to make its next hop the remote side.


If I'm on the 192.168.30.0 side and go to say www.google.com the router will look at that and immediately nat me and push me out my 0.0.0.0 0.0.0.0 route directly to the internet.  I need it to take all web requests, and point them out the remote side as the gateway. So its leaving for the internet from 2.2.2.2.  Thats why I assumed I needed to PBR to it would set the next hop on that interesting traffic, all web requests, then once the next hop was set to 192.168.10.1 the crypto map would match it and send it along.


Does that make more sense?


What I'm trying to accomplish.


www request--->192.168.30.1----VPN----192.168.10.1 ----- NAT 2.2.2.2 --- Out to the internet..  


Right now I'm getting.


www request --->192.168.30.1 -- NAT 1.1.1.1 ---> out to internet

blau grana Sat, 02/01/2014 - 02:44
User Badges:
  • Gold, 750 points or more

Hi Bruce,

Now it is making much more sense.

PBR is really not necessary for what you area trying to accomplish.


crypto map IOFVPN 1 ipsec-isakmp

  description IoM

set peer 2.2.2.2

  set transform-set IOFSET2

  match address 154

  reverse-route static


ACL 154 is matching interesting traffic so if ACL 154 match traffic, it will be encrypted and send to peer 2.2.2.2.


Change ACL 154 to match your needs:


access-list 154 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 154 permit tcp 192.168.30.0 0.0.0.255 any eq 80

access-list 154 permit tcp 192.168.30.0 0.0.0.255 any eq 443


Also dont forget to change ACL on peer 2.2.2.2 symetrically.


Best Regards

Please rate all helpful posts and close solved questions

TheEditor Sat, 02/01/2014 - 05:08
User Badges:

I changed the ACL.  When doing a show crypto ipsec sa I now see 3 protected vrf's matching the 3 acl statements.  I'm not seeing the encap counter go up at all on either 80 or 443 and I can still get to the internet through my normal gateway.


Not only that but I did a tcpdump tcp 80 on both interfaces of the remote side and both were 0, that makes me think there is no traffic getting there.


In the bigger picture won't I need something telling all the web traffic that it's next hop is 192.168.10.1 since that is the interface on the remote side that it needs to hit to be nat'ed correctly?


This might be a bit easier if the other side were another cisco and not an Openswan instance. 


I'm not sure how to proceed here. What if any other counters should I be looking at here?  I know the VPN is up and functioning, now it's just trying to get the correct traffic across it,.


Thanks

Jon Marshall Sat, 02/01/2014 - 05:42
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Bruce


In the bigger picture won't I need something telling all the web traffic that it's next hop is 192.168.10.1 since that is the interface on the remote side that it needs to hit to be nat'ed correctly?

The access-list you use with your crypto map is what tells your router which packets to send via the VPN. So as long as both ends match ie. the same traffic is matched at both ends for sending down the VPN tunnel then you don't need to add anything in terms of routing or PBR.


As already mentioned you need to make sure that the other end of the VPN is also configured for the same traffic.


Jon

TheEditor Sat, 02/01/2014 - 05:54
User Badges:

I'm wondering at this point if I'm going about this the wrong way.  My goal here is to use my remote endpoint as my gateway to the web. Encrypt all web traffic leaving this site, traverse VPN, get to the other side then decrypted and out to the web.


I think I understand what is not working here but I have no idea how to make it work.  The VPN is created between 2 real ip's.  1.1.1.1 and 2.2.2.2.  That gives visibility from one internal subnet to the other. 192.168.30.0 and 192.168.10.0.   That works. I can ping back and forth happily from internal to internal.


So if by just flagging port 80 traffic as interesting traffic and pushing it across the VPN that doesn't solve this issue.


That's why I was going with the policy based routing.  I figured that by setting next hop of 192.168.10.1 it would basically say "Oh someone from 192.168.30.0 wants a web site, well their gateway is 192.168.10.1 so we'll send them there, AND since I see by our crypto map we have to encrypt that over the VPN we will. "  That traffic would then hit 192.168.10.1 and be decrypted, NAT'ed out the external addy on that side, 2.2.2.2 and off to the webserver of choice.  I'm guessing this thinking is wrong since it didnt work.


I think maybe I'm missing a concept here. 


If the ACL's didnt match then the tunnels would never come up. Secondly even if the acl on the other side was wrong I should still see the encap counter go up each and every time I try to hit a web site becuase it should be trying to send that across the vpn correct? At least if that number was going up then I'd know it would be somethign on the other end.


Due to the other side not being cisco there really are not any acls persay. I'm running iptables but I've opened them wide up to make sure that wasnt it.  As for the ipsec config that's irrelevant isnt it since the tunnels are up and functioning,  Here is the config just in case it matters, it's short.


conn IOF

                authby=secret

                type=tunnel

                left=2.2.2.2

                leftsubnet=192.168.10.0/24

                leftid=2.2.2.2

                right=1.1.1.1

                rightsubnets=192.168.30.0/24,0.0.0.0

                rightid=1.1.1.1

                esp=aes192-sha1

                keyexchange=ike

                ike=aes192-sha1

                phase2=esp

                salifetime=43200s

                pfs=yes

                auto=start

                dpdaction=restart


So if there is an easy way to accomplish this I'd love to hear it. If not I'm not even sure what to debug.  I'm stuck on the fact that the encap # doesnt move past 0  which to me says that its not getting anything to encrypt. 


Thanks

Jon Marshall Sat, 02/01/2014 - 06:07
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Bruce


Can you try modifying your NAT statement. At the moment it is only not doing NAT if the destination IP is 192.168.10.x but the destination for the internet is any so in your NAT access-list you need to add statements for http/https and whatever else. So what is happening is the router does NAT on your source IPs and then the traffic does not match the access list used in your crypto map. So you would need something like -


ip access-list extended NAT

deny   ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

deny  ip 192.168.30.0 0.0.0.255 any eq http

etc.. for any specific ports you want to go via the VPN to the internet

permit ip any any


Jon

TheEditor Sat, 02/01/2014 - 06:14
User Badges:

Jon,


Tried that.  added deny tcp 192.168.30.0 0.0.0.255 any eq www .  As soon as that was added I get no web.   I ran this on the remote end


tcpdump -i any dst port 8


I get nothing.  Not a single packet.


Thanks

Jon Marshall Sat, 02/01/2014 - 06:22
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Bruce


When you did this do you see the encaps go up ?


Can you post the current config you are working with. If your acls for the crypto map and NAT are right now and the encaps go up it is a problem at the other end no matter what tcpdump says


Jon

TheEditor Sat, 02/01/2014 - 06:35
User Badges:

I may have put my foot in my mouth.. I was strictly looking at  #pkts encaps, and as you see its 0.  Does #send erros mean an issue on the other side?


protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/6/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/6/80)

   current_peer 2.2.2.2 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 182, #recv errors 0


     local crypto endpt.: 1.1.1.1, remote crypto endpt.: 37.235.55.196

     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

     current outbound spi: 0x0(0)



Here is current config.


version 12.4

service timestamps debug uptime

service timestamps log datetime

service password-encryption

!

hostname Hex-2811

!

boot-start-marker

boot system flash c2800nm-advsecurityk9-mz.124-24.T5.bin

boot-end-marker

!

no logging buffered

aaa new-model

aaa session-id common

clock timezone EST -5

clock summer-time EDT recurring

no ip source-route

!

!

ip cef

!

no ip bootp server

ip domain name hexhome.int

ip name-server 192.168.30.8

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

!

ipv6 unicast-routing

!

voice-card 0

no dspfarm

!        

archive

log config

  hidekeys

!

!

ip ssh version 2

!

!

crypto isakmp policy 1

encr aes 192

authentication pre-share

group 2

lifetime 43200

crypto isakmp key ******* address 2.2.2.2

!

!

crypto ipsec transform-set IOFSET2 esp-aes 192 esp-sha-hmac

!

crypto map IOFVPN 1 ipsec-isakmp

description IOM

set peer 2.2.2.2

set transform-set IOFSET2

match address 160

!

!

interface FastEthernet0/0

description Internal 192 Network

ip address 192.168.30.1 255.255.255.0

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

duplex full

speed 100

!

interface FastEthernet0/1

ip address dhcp

ip access-group 112 in

no ip redirects

no ip unreachables

ip accounting access-violations

ip nbar protocol-discovery

ip nat outside

ip virtual-reassembly

no ip route-cache cef

no ip mroute-cache

duplex auto

speed auto

no cdp enable

no mop enabled

crypto map IOFVPN

!

ip forward-protocol nd

!

ip flow-export source FastEthernet0/0

ip flow-export version 5

ip flow-export destination 192.168.30.45 3001

!

no ip http server

ip http access-class 23

ip http authentication local

no ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

ip nat inside source static tcp 192.168.30.60 443 interface FastEthernet0/1 443

ip nat inside source static tcp 192.168.30.20 21 interface FastEthernet0/1 21

ip nat inside source route-map POLICY-NAT interface FastEthernet0/1 overload

ip nat inside source static tcp 192.168.30.13 80 interface FastEthernet0/1 80

ip nat inside source static tcp 192.168.30.25 44394 interface FastEthernet0/1 44394

ip nat inside source static tcp 192.168.30.13 22 interface FastEthernet0/1 22

ip nat inside source static tcp 192.168.30.12 32400 interface FastEthernet0/1 32400

ip nat inside source static udp 192.168.30.12 32400 interface FastEthernet0/1 32400

ip nat inside source static udp 192.168.30.25 44394 interface FastEthernet0/1 44394

ip nat inside source static tcp 192.168.30.105 5901 interface FastEthernet0/1 5901

ip nat inside source static tcp 192.168.30.200 9443 interface FastEthernet0/1 9443

!

ip access-list extended NAT

deny   tcp 192.168.30.0 0.0.0.255 any eq www

deny   ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

permit ip any any

!

access-list 112 remark Explicit accept and deny

access-list 112 deny   udp any any eq snmp

access-list 112 deny   ip host 50.17.67.227 any

access-list 112 deny   ip host 1.93.27.33 any

access-list 112 deny   tcp any any eq telnet

access-list 112 permit tcp host 37.235.50.117 any eq ftp log

access-list 112 permit tcp host 5.255.80.84 any eq ftp log

access-list 112 permit tcp host 66.228.62.226 any eq ftp log

access-list 112 permit tcp host 72.25.5.126 any eq 5901 log

access-list 112 permit tcp host 72.25.5.126 any eq 11111 log

access-list 112 permit tcp host 72.25.5.126 any eq 8000 log

access-list 112 deny   tcp any any eq ftp log

access-list 112 deny   tcp any any eq 3389 log

access-list 112 deny   tcp any any eq 5901 log

access-list 112 deny   tcp any any eq 11111

access-list 112 deny   tcp any any eq 8000

access-list 112 permit ip any any

access-list 153 permit tcp 192.168.30.0 0.0.0.255 any eq www

access-list 154 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 155 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 160 permit ip 192.168.30.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 160 permit tcp 192.168.30.0 0.0.0.255 any eq www

access-list 160 permit tcp 192.168.30.0 0.0.0.255 any eq 443

snmp-server community public RO

no cdp run

!

route-map VPN_WEB permit 1

match ip address 153

set ip next-hop 192.168.10.1

!

route-map POLICY-NAT permit 10

match ip address NAT

blau grana Sat, 02/01/2014 - 08:22
User Badges:
  • Gold, 750 points or more

Hi Bruce,


Do you have access to both devices in this scenario? Are they cisco devices? Can you upload running-config for both devices?


To be honest I am not fan of crypto-maps and everytime I can I try to deploy static dynamic VTI. It is much more straightforward solution and also so much easier to troubleshoot.

If you have access to both devices, I can provide you a config modification for both devices.


Best Regards

Please rate all helpful posts and close solved questions

TheEditor Sat, 02/01/2014 - 08:34
User Badges:

You are the second person to suggest VTI to me.   I'm more than happy to upload both configs.  Unfortunately the second device is not a cisco. Its a linux box running Openswan.  After talking to jon earlier it turns out that yes the issue is that the tunnels are not coming up.  The only one I can get to come up is the subnet to subnet one. As soon as I try to get the 192.168.30.0 0.0.0.255 any eq www or 443 up the tunnel never forms.  I'm almost positive it's on the openswan side.


I've since removed everything and am trying to just get a single tunnel up, the port 80 one.  So far it's not coming up.


If this were a second cisco device I think I might have been done a long time ago with this.

blau grana Sat, 02/01/2014 - 08:42
User Badges:
  • Gold, 750 points or more

ok, then I assume that both sites have to have same ACLs to establish connection. So in current topology you have probably only two options.


1) delete all modification which you done and use IPsec tunnel only for LAN-to-LAN traffic.


2) configure default route so all traffic will run via IPsec tunnel, although I am not sure if this is suitable for you or even if this is possible with Openswan [I have never used it].


Best Regards

Please rate all helpful posts and close solved questions

TheEditor Sat, 02/01/2014 - 08:44
User Badges:

I considered that but cant. I need certain traffic to still originate from here, I only want http/https routed over the VPN.

Thanks

blau grana Sat, 02/01/2014 - 09:14
User Badges:
  • Gold, 750 points or more

Did you consider to use proxy? You said that second device is linux box, so if you configure this linux box as proxy server for http/https traffic, web traffic will run via IPsec tunnel [I assume that linux box has IP from 192.168.10.0/24 subnet] and from linux box to the internet.


Best Regards

Please rate all helpful posts and close solved questions

TheEditor Sat, 02/01/2014 - 09:22
User Badges:

Yes! That was what I was acutally trying to accomplish here. I figured I needed to get the IPSEC tunnel up first which is why I was going through all this.   The proxy portion is painless, its the fact that I wanted it through an IPSEC tunnel that seems to have made this difficult.


Edit: I know I could do that now with what is working. I don't want to have to set a proxy address on al machines. I want it all handled by the router itself.

Jon Marshall Sat, 02/01/2014 - 06:49
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Bruce


Config looks okay just a few little things -


1) your crypto map acl includes https but your NAT acl doesn't. Doesn't matter as long as you are testing with http.


2) you have this NAT statement -


ip nat inside source static tcp 192.168.30.13 80 interface FastEthernet0/1 80


so just to clarify, you are not testing web access from this address are you as it will NAT the source IP and then the crypto map acl won't match.

 

Edit - ignore 2) above. I misread it and it doesn't apply to outbound traffic.


In terms of the crypto output can you -


1) edit your post (which you can do) and remove the public IPs. Just a precaution but we don't need to see them for troublshooting and best not to publish that sort of information.


2) send errors look like an issue on this end as opposed to receive errors. So can you clear the crypto tunnel to start afresh and then try connecting and see what the output is showing.


Jon

TheEditor Sat, 02/01/2014 - 07:01
User Badges:

1. I'm only testing http right now. Plus just easier to only have to remove one line when I need web access back.


2. nope not using that machine.


1. I edited that. Thanks, I've been trying to remember to clear those ips on all posts.


2. I did a clear crypto sa.  


Then I added back in the deny statement to my acl for www traffic.  Then I tried to go to a few sites.  I got nowhere.  Here is the output from a show crypto ipsec sa


   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/6/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/6/80)

   current_peer 2.2.2.2 port 500

     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 315, #recv errors 0


     local crypto endpt.: 1.1.1.1, remote crypto endpt.: 37.235.55.196

     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1

     current outbound spi: 0x0(0)


Same as last time.  

Jon Marshall Sat, 02/01/2014 - 07:05
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Bruce


Your IPSEC tunnel is not establising correctly ie. there are no phase 2 tunnels coming up. Now we know you can get the tunnels to come up because they did before all the changes. Can you make sure any changes you have made are matched at the other end.


Obviously the NAT is not relevant as that is only local to the router.


Jon

TheEditor Sat, 02/01/2014 - 07:31
User Badges:

Yeh, I see that now.  Actually I don't think they were ever up.  Looking below i just assumed that if I saw it there it was up. I didn't notice the Active SA's was 0 on both the 443 and the 80. 


So yes it looks like thost are not up.   I have 0 idea how to get them up either.  I haven't had much luck with finding any useful information on doing this with openswan.  Doing different subnets is ok but ports, I'm still looking around and maybe I'll have to change how i do this.  I ran into this when I first started to do this.  My acl for my vpn was like the port 80 one below and it would never come up.


Thanks for all the help.  I'll post back if I come up with anything.  For now I'm stumped.


  IPSEC FLOW: permit 6 192.168.30.0/255.255.255.0 0.0.0.0/0.0.0.0 port 443

        Active SAs: 0, origin: crypto map

        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0

        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

  IPSEC FLOW: permit 6 192.168.30.0/255.255.255.0 0.0.0.0/0.0.0.0 port 80

        Active SAs: 0, origin: crypto map

        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0

        Outbound: #pkts enc'ed 0 drop 229 life (KB/Sec) 0/0

  IPSEC FLOW: permit ip 192.168.30.0/255.255.255.0 192.168.10.0/255.255.255.0

        Active SAs: 4, origin: crypto map

        Inbound:  #pkts dec'ed 35 drop 0 life (KB/Sec) 4395176/3536

        Outbound: #pkts enc'ed 36 drop 6 life (KB/Sec) 4395176/3536

TheEditor Mon, 02/03/2014 - 02:28
User Badges:

Here is the answer to this if anyone is interested.


The policy map was never going to work the way it was previously. There was no place to route the traffic.   What I needed was a gre tunnel.

interface Tunnel0
ip address 10.10.10.2 255.255.255.252
ip mtu 1420
tunnel source 1.1.1.1
tunnel destination 2.2.2.2
crypto map IOFVPN

and a route to point to the internal subnet on the remote side with a gateway of the remote side.

S    192.168.10.0/24 [1/0] via 10.10.10.1

I've never used gre before but I will now. Getting the tunnel up was pretty basic both on the cisco and linux ( openswan ) side. Once that was up and running I tested without ipsec.

On my fa0/0 interface, my internal I put:

ip policy route-map PROXY-REDIRECT

route-map proxy-redirect permit 100
match ip address PROXY-REDIRECT
set ip next-hop recursive 192.168.10.1

The matching ACL is:

ip access-list extended proxy-redirect
deny   tcp host 192.168.30.13 any eq www
permit tcp 192.168.30.0 0.0.0.255 any eq www
permit tcp 192.168.30.0 0.0.0.255 any eq 443
permit tcp 192.168.30.0 0.0.0.255 any eq irc
permit tcp 192.168.30.0 0.0.0.255 any eq 6667
deny   tcp 192.168.30.0 0.0.0.255 any eq 5938
deny   tcp any any
deny   udp any any
deny   ip any any

As soon as I added that my traffic started passing the way I wanted it. I'll note here that this ACL could be shrunk. I added the implicit deny's because I was having the odd traffic pass over the link.

Once was verified working then I just needed to wrap it in ipsec. Configuring the Cisco side was easy.

crypto isakmp policy 1
encr aes 192
authentication pre-share
group 2
lifetime 43200
crypto isakmp key *********** address 2.2.2.2
!
!
crypto ipsec transform-set IOFSET2 esp-aes 192 esp-sha-hmac
mode transport
!
crypto map IOFVPN 1 ipsec-isakmp
description IOM
set peer 2.2.2.2
set transform-set IOFSET2
match address IPSEC-GRE-IOF

ip access-list extended IPSEC-GRE-IOF
permit gre host 1.1.1.1 host 2.2.2.2

** Must use transport mode. It took me a bit to figure that one out.

Apply that crypto map to both f0/1 and tun0 and you have a tunnel.

The openswan side is what gave me trouble though this whole thing. Their config is a bit odd and it just took some getting used to.

At the end of the day all traffic that I want is peeled off and routed through an ipsec protected gre tunnel to a remote endpoint.

Enjoy.

Actions

This Discussion

Related Content