We have dynamic public IP addresses at remote offices, with aggressive mode VPN to the main site in star topology. There are various reasons we need a GRE tunnel in our case (including a requirement for multicast routing). The GRE/IPSec guide has been really helpful:
Will the following be okay, in principle? Mainly, I'm wondering if the VPN selectors are okay permitting a single host, relating to secondary inside interface addresses. Our goal is to route traffic between the two LANs.
MAIN-OFFICE.CFG |
---|
! ip crypto ! crypto ike policy 101 no initiate respond aggressive local-id fqdn vpn.example.com peer any attribute 1 encryption aes-256-cbc authentication pre-share ! crypto ike remote-id fqdn remote-1.example.com preshared-key PSK-goes-here ike-policy 101 crypto map VPN 101 no-mode-config no-xauth ! crypto ipsec transform-set esp-aes-256-cbc-esp-sha-hmac esp-aes-256-cbc esp-sha-hmac mode tunnel ! crypto map VPN 101 ipsec-ike description Remote Office 1 match address VPN-101-vpn-selectors set transform-set esp-aes-256-cbc-esp-sha-hmac ike-policy 101 ! ! interface eth 0/1 description LAN ip address 10.1.1.1 255.255.255.0 ip address 10.1.255.1 255.255.255.0 secondary ip access-policy Private no shutdown ! interface eth 0/2 description ISP ip address 12.34.56.1 255.255.255.0 ip access-policy Public crypto map VPN no shutdown ! interface tunnel 1 gre ip description Remote Office 1 ip address 10.255.255.1 255.255.255.252 ip mtu 1400 ip access-policy Private tunnel source 10.1.255.1 tunnel destination 10.2.255.1 keepalive no shutdown ! ! ip access-list standard wizard-ics remark NAT list wizard-ics permit any ! ip access-list extended Trusted remark Trusted permit ip any any ! ip access-list extended VPN-101-vpn-selectors remark Remote Office 1 permit gre host 10.1.255.1 host 10.2.255.1 permit ip host 10.1.255.1 host 10.2.255.1 ! ! no ip policy-class Private rpf-check ip policy-class Private allow list self self allow list VPN-101-vpn-selectors stateless allow list Trusted policy Private nat source list wizard-ics interface eth 0/2 overload policy Public ! ip policy-class Public allow reverse list VPN-101-vpn-selectors stateless ! ! ip route 10.2.1.0 255.255.255.0 10.255.255.2 ! ! end |
REMOTE-OFFICE-1.CFG |
---|
! ip crypto ! crypto ike policy 101 initiate aggressive respond aggressive local-id fqdn remote-1.example.com peer 12.34.56.1 attribute 1 encryption aes-256-cbc authentication pre-share ! crypto ike remote-id fqdn vpn.example.com preshared-key PSK-goes-here ike-policy 101 crypto map VPN 101 no-mode-config no-xauth ! crypto ipsec transform-set esp-aes-256-cbc-esp-sha-hmac esp-aes-256-cbc esp-sha-hmac mode tunnel ! crypto map VPN 101 ipsec-ike description Main Office match address VPN-101-vpn-selectors set peer 12.34.56.1 set transform-set esp-aes-256-cbc-esp-sha-hmac ike-policy 101 ! ! interface eth 0/1 description LAN ip address 10.2.1.1 255.255.255.0 ip address 10.2.255.1 255.255.255.0 secondary ip access-policy Private no shutdown ! interface eth 0/2 description ISP ip address 12.34.56.2 255.255.255.0 ip access-policy Public crypto map VPN no shutdown ! interface tunnel 1 gre ip description Main Office ip address 10.255.255.2 255.255.255.252 ip mtu 1400 ip access-policy Private tunnel source 10.2.255.1 tunnel destination 10.1.255.1 keepalive no shutdown ! ! ip access-list standard wizard-ics remark NAT list wizard-ics permit any ! ip access-list extended Trusted remark Trusted permit ip any any ! ip access-list extended VPN-101-vpn-selectors remark Main Office permit gre host 10.2.255.1 host 10.1.255.1 permit ip host 10.2.255.1 host 10.1.255.1 ! ! no ip policy-class Private rpf-check ip policy-class Private allow list self self allow list VPN-101-vpn-selectors stateless allow list Trusted policy Private nat source list wizard-ics interface eth 0/2 overload policy Public ! ip policy-class Public allow reverse list VPN-101-vpn-selectors stateless ! ! ip route 10.1.1.0 255.255.255.0 10.255.255.1 ! ! end |
Thanks!
Thank you for asking this question in the support community. I don't see any issues with this configuration, the concept is the same as usual, with the only difference that I can see is that you are using a secondary IP address instead of the primary. The only thing to keep in mind, as I'm sure you're aware, is the remote site will have to initiate the connection for the tunnel to come up.
Please, let me know what additional questions you have.
Levi
Thank you for asking this question in the support community. I don't see any issues with this configuration, the concept is the same as usual, with the only difference that I can see is that you are using a secondary IP address instead of the primary. The only thing to keep in mind, as I'm sure you're aware, is the remote site will have to initiate the connection for the tunnel to come up.
Please, let me know what additional questions you have.
Levi
Thanks, Levi. I used secondary addresses to terminate the GRE tunnel in this example because I wasn't sure what might overlap or conflict if we terminated with primary address. There would be a route in that case to the remote LAN subnet over the tunnel that's terminated with an address in that same subnet. Is that actually okay? It would be simpler; I just wasn't sure it would work.
Chris