Multicast NAT on GRE/IPSec site to site VPN

[guylainrm]

Hi,

We are trying to set up a site to site VPN tunnel to carry multicast traffic (e.g. 239.192.150.100) between our sender (behind Router A) and a receiver at our customer (Behind Router B). Both routers are Cisco 1811.

Our customer cannot receive traffic with our private IP as a source.

Therefore, on the Router A side (VLAN1 192.168.14.x), we need to NAT the source IP of the multicast traffic to one of our public address (e.g. A.B.C.215).

Since there are only 3 private servers behind Router A, and the customer requires a specific address, we can use static NAT.

Our problem is that the NAT does not take place before the multicast traffic enters the tunnel. It always shows up on the other end with the 192.168.14.x source IP address.

We've looked into NAT on a stick techniques to locally force a NAT over a loopback nat ourside interface with no luck.

In essence, this problem is akin to VPN between overlapping networks with the difference that the multicast traffic passes through the tunnel before undergoing a NAT.

Any help is greatly appreciated!

Guy

[pradeepde]

Cisco recommends using GRE tunnels with IPSec in tunnel mode to improve the flow of network traffic. IPSec in tunnel mode can be used as a tunneling protocol itself for unicast traffic, but not for multicast traffic. Multicast IPSec traffic requires a GRE tunnel, and that IPSec be used in either transport or tunnel mode. Cisco recommends using IPSec in tunnel mode for the best network traffic performance.

Changing these values increases the level of security; at the same time, however, it increases the processor overhead. The default behavior for SA rekeying is to base the new key in part on the old key to save processing resources. Perfect forward secrecy (PFS) generates a new key based on new seed material by carrying out a Diffie-Hellman (DH) exponentiation every time a new quick-mode (QM) SA needs new key generation. Again, this option increases the level of security but at the same time increases processor overhead. Cisco does not recommend changing the SA lifetimes or enabling PFS unless the sensitivity of the data mandates it. If you choose to change these values, make sure you include this variable when determining the network design. The strength of the Diffie-Hellman exponentiation is configurable; Groups 1 (768 bits), 2 (1024 bits), and 5 (1536 bits) are supported. Group 2 is recommended