cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6327
Views
0
Helpful
8
Replies

Forward UDP from site to site across vpn

Eric Brown
Level 1
Level 1

I have a site to site IPsec tunnel across the WAN from an 1841 to an 2811 router. I need a udp port to get to the other side but it is not receiving it. I have the ip forward-protocol and tried ip helper but it isn't working. Should I have the helper address on the LAN interface or the WAN? I have a phone switch on the LAN of each subnet trying to communicate with each other.

1 Accepted Solution

Accepted Solutions

narcis antonie
Level 1
Level 1

Hello Eric,

Is your UDP traffic unicast or multicast? If it is multicast it won't work until you change the encapsulation on the tunnel from IPSec to GRE. You can still add security by using an IPSec profile on that tunnel.

Best of luck.

View solution in original post

8 Replies 8

rvarelac
Level 7
Level 7

Hi Eric, 

The ip helper should be applied on the LAN interface, however why would you use the IP helper feature,  have you tried to add this UDP traffic to the  VPN interesting traffic?

-Hope it helps-

Randy

Thanks for the reply rvarelac. The crypto map and acl I am using is classifying all traffic to the other branch's subnet. I have an ACL denying all traffic to the branch for my split tunnel and then my crypto map's ACL classifies all to the branch for its tunnel. Here is the relevant config of one of the routers. I am trying to get the phone switch on 12.14 to talk to the one on 14.14 and vise versa.

crypto map nolan 10 ipsec-isakmp
set peer xxx.xxx.x.XXX (WAN of other BRANCH)
set transform-set sharks
match address TOR_PHONE
crypto map nolan 11 ipsec-isakmp
set peer XX.XXX.XX.xx (Corporate WAN)
set peer XX.XX.XX.xxx
set transform-set sharks
match address 121
!
!
!
!
!
interface FastEthernet0/0
description Comcast Cable WAN
ip address XX.XX.XXX.XXX 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
no cdp enable
crypto map nolan
!
interface FastEthernet0/1
description LAN
ip address 192.168.14.1 255.255.255.0
ip helper-address 192.168.12.14 (phone switch on other network)
no ip redirects
no ip unreachables
ip accounting output-packets
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
!
ip forward-protocol nd
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
ip forward-protocol udp netbios-ss
ip forward-protocol udp 50795!
!
ip nat inside source route-map nonat interface FastEthernet0/0 overload
ip route 0.0.0.0 0.0.0.0 XX.XX.XXX.XXX
!
ip access-list extended TOR_PHONE
permit ip 192.168.14.0 0.0.0.255 192.168.12.0 0.0.0.255
!
access-list 110 deny ip 192.168.14.0 0.0.0.255 172.17.0.0 0.0.255.255
access-list 110 deny ip 192.168.14.0 0.0.0.255 192.168.12.0 0.0.0.255
access-list 110 permit ip 192.168.14.0 0.0.0.255 any
access-list 121 permit ip 192.168.14.0 0.0.0.255 172.17.0.0 0.0.255.255
!
!
!
route-map nonat permit 10
match ip address 110

Hi Erick, 

I'm not sure , If I am understanding correctly, you want the host on the 192.168.14.x network to talk to 192.168.12.x across the S2S VPN ,  am I right ? 

If this is correct you should add those subnets to the VPN tunnel, example:

access-list 121 permit ip 192.168.14.0 0.0.0.255  192.168.12.0 0.0.255.255

Hope it helps 

Cheers, 

-Randy-

Access-list 121 is for the tunnel to HQ Sonicwall. We have a spoke and wheel topology between the branches and HQ. Each branch already has a tunnel to HQ but that doesn't mean they can talk to each other unless I put in static routes on the firewall from branch to branch. As the config shows we have a split tunnel between HQ and the internet. I have added a second crypto map entry for the tunnel between the 2 branches. The tunnel works between the 2 routers except for the UDP.

If the tunnel works for other type of traffic (TCP, ICMP) it might be a problem with the application itself, a capture on the inside interface of the routers might validate this.

https://supportforums.cisco.com/document/139686/configuration-example-embedded-packet-capture-cisco-ios-and-ios-xe

Hope it helps

-Randy-

narcis antonie
Level 1
Level 1

Hello Eric,

Is your UDP traffic unicast or multicast? If it is multicast it won't work until you change the encapsulation on the tunnel from IPSec to GRE. You can still add security by using an IPSec profile on that tunnel.

Best of luck.

Thanks narcis antonie, I was thinking along those lines but I wasn't sure that the point to point tunnel wouldn't work for UDP.

I did packet captures from both LAN and it looked like one side was getting a UDP unicast packet but the other side was not. They had the same configurations. I also saw some multicast UDP broadcasts that I think needed to get through for the phone switches to receive.

I decided to make a GRE tunnel and add the IPSEC on it. . The telephony admin checked his software and phones and said it is all working now! This was the first GRE tunnel I have made so it may not be perfect.

 

This is the relevant config that I changed:

crypto map nolan 10 ipsec-isakmp

set peer (WAN IP of other router)

set transform-set sharks

match address TOR_PHONE

 

interface Loopback1

ip address 10.1.1.1 255.255.255.0

 

interface Tunnel0

ip address 10.10.10.2 255.255.255.252

ip mtu 1400

ip tcp adjust-mss 1360

keepalive 10 3

tunnel source FastEthernet0/0

tunnel destination (WAN IP of other router)

 

router ospf 1

network 10.1.1.0 0.0.0.255 area 0

network 10.10.10.0 0.0.0.255 area 0

ip nat inside source route-map nonat interface FastEthernet0/0 overload

ip route 0.0.0.0 0.0.0.0 XX.XX.XXX.XX

ip route 192.168.12.0 255.255.255.0 Tunnel0

 

ip access-list extended TOR_PHONE

permit gre any any

 

access-list 110 deny   ip 192.168.14.0 0.0.0.255 172.17.0.0 0.0.255.255

access-list 110 deny   ip 192.168.14.0 0.0.0.255 192.168.12.0 0.0.0.255

access-list 110 permit ip 192.168.14.0 0.0.0.255 any

access-list 121 permit ip 192.168.14.0 0.0.0.255 172.17.0.0 0.0.255.255

Is there any suggestions or problems with doing it like this other than I plan on using better AES256 encryption. It shows it encrypting/decrypting when sh session detail. I also see the ACL for GRE any any getting the hits.

How can I also be certain that all of the traffic is encrypted as I think it is? Do more packet captures?

How is the loopback interface used for the OSPF and would it work for the source interface in this situation? It has to go across the WAN and internet so I made the source the WAN interface.

What improvements should I make? Can I restrict the tunnel to just host to host switches?

Any suggestions?

As an improvement you can do ipsec without manually configurating the crypto maps (which is a pain the .... if you ask me) by using ipsec profiles. Here is an example:

Start by creating an isakmp policy:

crypto isakmp policy 1

   encryption <whatever encryption you need e.g. aes or des>

   hash <sha or md5>

   authentication <whatever authentication you want e.g. pre-share or rsa-sig if you have a digital certificate for the router>

   group <diffie-hellman group id>

crypto isakmp key <key you want to use> address <corespondent physical interface ip address> [SM-optional]  !! you must define the key only if you selected authentication pre-share in the isakmp policy. If, on the other hand, all your routers have valid digital certificates issued by a CA recognized by all of them and you have authentication rsa-sig in the isakmp policy, then you don't need a crypto key.  The <key you want to use> should be identical on the corresponding router

You then need to create an IPSec transform-set (TS):

crypto ipsec transform-set <name of the TS> [transform 1 e.g.ah-sha-hmac] <transform 2 e.g. esp-aes 256> [transform 3 e.g. esp-sha-hmac]

!!you don't necessarily need the authentication header (AH) transform, depends on how paranoid you are :P. In most cases the second and the third are enough.

   mode <tunnel(default) or transport> !!specifies whether to encrypt the L3 header or not along with the payload, default is ok

Next you need to define an IPSec profile:

crypto ipsec profile <name of the profile>

   set transform-set <name of the TS>

Next you need to apply the ipsec profile on the tunnel interface:

interface Tunnel <no of the tunnel>

   ip address <IP of tunnel> <SM>

   tunnel mode gre !!(this is the default I think)

   tunnel source <physical interface e.g. FastEthernet 0/0>

   tunnel destination <IP address of the corresponding router physical interface>

   ip mtu 1400 !!not strictly needed but good practice to compensate for the additional overhead of the gre encapsulation

   ip tcp adjust-mss 1360 !!same as above

   tunnel protection ipsec profile <name of the profile>

In the end you need to configure the corresponding router accordingly and there you go, no access-lists and no crypto maps.

For the routing protocol, you only need to ad the ip adresses of the tunnel interfaces to ospf. For the physical interface you can create a static route. Nothing else should be routed directly through the physical interface without being gre encapsulated first. 

As for the NAT, you need to research more the order of operations, but in your case i believe the nat is done after the gre encapsulation and ipsec.