Script: Create an IPsec Tunnel running this shell, you can create gre tunnels over ipsec ------------------------------- -------------------------------------------------- ------------ #! / bin / sh
# ip IS "18", Right IS "20"
#
# Diff devnames area not needed, But make things more clear
DEV_LEFT = TUN18
DEV_RIGHT = TUN20
LEFT_IP = 192.168.2.18
LEFT_NET = 10.1.18.1 / 32
Right_IP = 192.168.2.20
Right_net = 10.1.20.1 / 32
Setup_left () {
DEV = $ dev_left
Local_ip = $ left_IP
Local_net = $ left_net
REMOTE_IP = $ RIGHT_IP
REMOTE_NET = $ RIGHT_NET
}
Setup_right () {
DEV = $ dev_right
Local_ip = $ RIGHT_IP
Local_net = $ RIGHT_NET
Remote_ip = $ left_IP
REMOTE_NET = $ LEFT_NET
}
Case "` / sbin / ip -4 -o addr show dev eth0` "in
* 192.168.2.18 *) setup_left
;
* 192.168.2.20 *) setup_right
;
*)
echo "error" ;;
ESAC
Case "$ 1" in
START)
MODPROBE IP_GRE
(set -x
IP Tunnel Add $ Dev Mode GRE Remote $ Remote_ip Local $ local_ip TTL 255
IP Link Set $ dev up Multicast On ### Doesnt Seems to Work for Zebra :(
IP AddR Add $ local_net peer $ remote_net dev $ dev $ dev
#ip Route Add $ Remote_Net Dev $ dev # Needed if you run bgp instead of ospf
)
;
STOP)
(set -x
IP Tunnel Del $ dev
)
Modprobe -r ip_gre
;
ESAC
-------------------------------------------------- --------------------------------------- Well, Start With your normal psk ipsec.conf file WITHLY A SINGLE Tunnel Defined (Host to Host) Between Your Two Gateways. Or Use X.509, or Rsasig - It Doesn't Matter. Just Get A Tunnel Between Your Two Sites Up, Host To Host.
Get Your Sa Established, And The EROUTE Happy. In Other Words, * Make Sure FREES / WAN IS WORKING * Before Going Any Further. Otherwise, It's a pain to debug.next Up, IT's GRE TIME:
$ transote_ip = Remote Side of Tunnel (What IPsec # ip is on remote gw is) $ local_ip = local ip address (What IPsec # ip is on IS)
IP Tunnel Add Site1tOSite2 Mode GRE Remote $ Remote_ip Local $ local_ip TTL 255IP Link Set Site1tOSite2 Upip Addr Add 192.168.0.1 Dev Site1tOSite2ip Route Add 192.168.0.2/32 dev site1tosite2
Remember to Reverse this on the Other Side ... EG:
IP Tunnel Add Site1Tosite2 Mode Gre Remote $ local_ip local $ remote_ip TTL 255IP Link Set Site1tOSite2 upip add 192.168.0.2 Dev Site1tOSite2ip Route Add 192.168.0.1/32 dev site1tosite2
NOTE: I'm Using Only 2 IP Addreses ... so it's a point to point limited link. Handy if you have lots of these and don't wanna Waste / 24's Each Time.
Make Sure It Works - Ping The Other End of The Gre Tunnel. Check Iptables Rules So Traffic Won't Be Dropped. You'Ve Probably Done this already if you're adding this to a working frees / wan setup :)
THEN, ROUTE wherever you want over the tunnel - EG:
IP route add 172.16.0.0.0.0.2 dev site1tosite2
OR, Do Something Completely Insane (Like Me) and Run Zebra / BGPD on Both Ends Dynamically. NEVER ISSUE AN "IP Route [Add | Delete]" Command Again!
And That's About It. The Exercise of Putting All of this Into Custom_Updown Scripts is Left to The Reader:) --------------------------- -------------------------------------------------- -------------- i Must Be missing.
Why Would You Want to Establish An Ipsec Tunnel from Site to Site and the Run A GRE TUNNEL? TIA. -------------------------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------- -------------- Several Reasons. The Ons That Come to Mind Are:
1) Simplified config. If you have gateway A and gateway B, and behind Athere are N networks and behind B there are M networks, then you will needto define N * M connections with straight ipsec. If you use a gre tunnel, then you will only need to define one connection, build one tunnel, and thenadd M routes on A and N routes on B. with reasonably large networks, alinear increase in complexity with network size is * significantly * easier tomanage than an exponential increase in complexity with network Size. ONCE NAND M GET To BE ABOVE 10 OR SO, IT CAN Start To Get Painful.
2) Non-IP protocols. Say, for instance, you've got a nice IPX network attwo sites with internet connections. You * could * buy a leased line betweenthe two for all IPX traffic, but that would be expensive. You * could * tunnel it all in the clear, but that would be insecure. you * could * writeyour own IPX-over-IP-with-spiffy-encryption protocol, but that would bedifficult. Or, you could use an ipsec encrypted gre tunnel, and EverythingWould (Theoretical) Work.
3) fault-tolerant routing. There's very little built in to the ipsecprotocols to either detect when a remote peer is no longer responding, or tofind a better way to get to the networks that were previously reachablethrough that dead peer. Gre tunnels, when combined With Standard RoutingProtocols, Make It Easier To do this.
On that note, I have done the above (ipsec gre ospf / eigrp) extensively oncisco boxes. However, as much as I have been saying that it's a cool thingto do, I have just today finished setting up my first combination offreeswan / ipsec gre zebra / ospf. I know that Ken has done the same thing withzebra / bgp, and there have been some questions about how this sort of thingis done, so I wanted to share some of my experiences / gotchas.First, my biggest moment of "d'oh!", make sure your firewall rules allowospf traffic on your gre interfaces:.) Second, zebra looks a lot like cisco, but acts somewhat differently Thereare three things that need to be done in ospfd.conf. to make this work: 1) for each tunnel interface, do:. interface {tunnel-name} ip ospf network non-broadcastbecause zebra does not seem to like listening for multicast messages onvirtual interfaces (which sucks) A tunnel interface * should * Be apoint-to-point seem to work what Way.2) Because of 1, you need to define n eighbors with statements like:. router ospf neighbor {tunnel ip address of remote peer} 3) for some incredibly wierd reason, normal network statements like onewould use for other interfaces do not work network statements for gre (oractually any point-to-point ) interfaces have to be the ip address of thelocal tunnel interface and have to be / 32, like: router ospf network 192.168.1.1/32 area 0even if the tunnel is 192.168.1.1/30 and you would expect a statement like "network 192.168 .1.0 / 30 Area 0 "Or Even" Network 192.168.0.0/16 Area 0 "Towork, IT WON 'TOK, ZEBRA WILL NOTIVATE OSPF on The Interface, Andnothing Will Happen. Which is * real- frustrating.
-Joe ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ------------------------------ On Tue, 15 Oct 2002, Joe Patterson Wrote:> Several Reasons. The ones That Come To mind are:>> 1) Simplified config If you have gateway A and gateway B, and behind A> there are N networks and behind B there are M networks, then you will need> to define N * M connections with straight ipsec.. If you use a gre tunnel,> then you will only need to define one connection, build one tunnel, and then> add M routes on A and N routes on B. with reasonably large networks, a> linear increase in complexity with network size IS * SIGNIFICANTLY * Easier To> Manage Than An Exponential Increase In Complexity With Network size. Once n> and m get to be Above 10 or So, IT CAN Start to get painful.
That was my primary reason for doing this. I run what I term an Enterprise Class VPN between two datacenters. I have 2 GW's @ each side, running Heartbeat for IP Address takeover, ospfd for internal routing, and now BGP between 4 ISPs and between my own sites. My config is nessecarily complex, so I welcome simplicity. I also have several business partner VPN's, run off various devices. I static-route thier remote networks on my GW's, and ospf / bgp redistribute them to my other sides, So All Traffic To The Business Partner Goes THROUGH 1 LINK. MUCH SIMPLER THAN GIVING A Partner Connections To All of your Sites, and Much Simpler To Secure.
> 3) fault-tolerant routing. There's very little built in to the ipsec> protocols to either detect when a remote peer is no longer responding, or to> find a better way to get to the networks that were previously reachable> through that dead Peer. GRE Tunnels, When Combined with Standard Routing> Protocols, make it it it easier to do this.yup. My HeartBeat FreeS / Wan Combo Needs Dynamic Routing to Work Effectivly.
> ON That Note, I Have Done The Above (IPsec GRE OSPF / EIGRP) Extensity ON> Cisco Boxes. However, As Much As I Have Been Saying That's A Cool Thing> To do, i Have Just Today Finished Setting Up My First Combination Of> FreeESWAN / IPSEC GRE ZEBRA / OSPF. I Know That Ken Has Done The Same Thing with> Zebra / BGP, and There Have Been Some Questions About How this Sort of Thing> IS DONE, SO I WANTED TO Share Some of My Experiences / Gotchas.>> First, My Biggest Moment Of "D'Oh!", Make Sure Your FireWall Rules Allow> OSPF Traffic On Your Gre Interfaces:)> Second, Zebra Looks a Lot Like Cisco, But . acts somewhat differently There> are three things that need to be done in ospfd.conf to make this work:> 1) for each tunnel interface, do:> interface {tunnel-name}> ip ospf network non-broadcast> because zebra Doesn't Seem to Like Listening for Multicast Messages On> Virtual Interfaces (Which Sucks). A Tunnel Interface * Should * Be a> Point-To-Point. But it doesn't see Work That Way.> 2 ) Because of 1, you need to define neighbors with statements like:> router ospf> neighbor {tunnel ip address of remote peer}> 3) for some incredibly wierd reason, normal network statements like one> would use for other interfaces do not Work. NetWork Statements for Gre (or> Actually Any Point-Point) Interfaces Have to Be The IP Address of The> Local Tunnel Interface:> Router Ospf> Network 192.168.1.1/32 Area 0> Even if the tunnel is 192.168.1.1/30 and you would expect a statement like> "NetWork 192.168.1.0/30 Area 0" Or Even "NetWork 192.168.0.0/16 Area 0" to "
work, it will not work, zebra will not activate ospf on the interface, and> nothing will happen. Which is * really * frustrating.>> -Joe> Thanks for doing this and sharing the knowledge. Pat Felt (see messages from the past few days) has also attempted this, and got it working today. His experience matches yours 100%, down the network 192.168.1.1/32 area 0 config lines. I will be including both your's and his information in my FreeS / WAN Dynamic Routing Doc (Forthuing) ------------------------------------------- -----------------------------------------> i must be missing something.>> Why Would You Want to Establish An Ipsec Tunnel from Site To Site and the> Run A GRE TUNNEL?>> TIA.>
Many Reasons. Quickly:
* GRE supports Broadcast Multicast IPSec does not * Use dynamic routing protocols to add / remove routes over the ipsec interface * Tunnel over multiple IPSec "hops" in a fully encrypted mutli-hop network * Because you can:..) --- -------------------------------------------------- --------------------------------
