Route-map not sending traffic over vpn.

TheEditor · ‎01-31-2014

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

Richard Bradfield · ‎01-31-2014

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

TheEditor · ‎02-01-2014

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 · ‎02-01-2014

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

Best Regards Please rate all helpful posts and close solved questions

TheEditor · ‎02-01-2014

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 · ‎02-01-2014

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

Best Regards Please rate all helpful posts and close solved questions

TheEditor · ‎02-01-2014

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 · ‎02-01-2014

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 · ‎02-01-2014

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 · ‎02-01-2014

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 · ‎02-01-2014

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 · ‎02-01-2014

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 · ‎02-01-2014

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