cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Valued Contributor
Valued Contributor

Will this GRE over IPSec configuration work?

Jump to solution

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!

Labels (2)
0 Kudos
1 Solution

Accepted Solutions
Anonymous
Not applicable

Re: Will this GRE over IPSec configuration work?

Jump to solution

:

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

View solution in original post

2 Replies
Anonymous
Not applicable

Re: Will this GRE over IPSec configuration work?

Jump to solution

:

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

View solution in original post

Highlighted
Valued Contributor
Valued Contributor

Re: Will this GRE over IPSec configuration work?

Jump to solution

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