I think people are missing my origonal point. My implementtation using gif
tunnel and an ipsec transport to encrypt the gf traffic works fine and
always has done, I am therefore not overly bothered about gif tunnels. I
just cant understand why when I change the tunnel type to gre and update the
ipsec policy to encrypt all gre traffic it stops working. GRE is fine when
its not encrypted but it doesnt when it is. TCPdunmping shows no other
additiononal traffic so I dont understand why the 2nd of the 2 polices
doesnt work while the 1st on does

tunnel config and policy. This works


gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        tunnel inet A --> B
        inet 192.168.250.2 --> 192.168.250.1 netmask 0xfffffffc


spdadd 0.0.0.0/0 0.0.0.0/0 4 -P out ipsec esp/transport//require;
spdadd 0.0.0.0/0 0.0.0.0/0 4 -P in ipsec esp/transport//require;



This doesnt

gre0: flags=9051<UP,POINTOPOINT,RUNNING,LINK0,MULTICAST> mtu 1476
        tunnel inet A -> B
        inet 192.168.250.2 --> 192.168.250.1 netmask 0xfffffffc

spdadd 0.0.0.0/0 0.0.0.0/0 gre -P out ipsec esp/transport//require;
spdadd 0.0.0.0/0 0.0.0.0/0 gre -P in ipsec esp/transport//require;

----- Original Message -----
From: "David Kelly" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Brent Wiese" <[EMAIL PROTECTED]>
Sent: Wednesday, March 19, 2003 1:51 AM
Subject: Re: ipsec and gre tunnels


> On Tuesday 18 March 2003 10:59 am, Brent Wiese wrote:
> > It's a common mistake to do both gif and ipsec.
> >
> > I realize many of the handbooks you find say to do it. They're wrong.
> > They've been contacted and most won't change them, which just
> > misleads more people.
> >
> > Use ipsec in tunnel mode instead of transport and ditch gif.
>
> I've heard that before. So with a RELENG_4 system I dropped my gif
> tunnel and it worked!
>
> Then some time after 4.7-RELEASE somebody changed something so that the
> contents of an ESP packet could not be distinguished by ipfw from
> non-ESP packets on the same interface. So my rule for blocking RFC 1918
> addresses on the public interface was blocking my own tunneled packets.
>
> Then I reverted the system to RELENG_4_7 and my IPSec tunnel failed to
> operate until I resumed initializing the gif interface as I was
> originally doing.
>
> /etc/ipsec.conf looks like this:
>
> flush;
> spdflush;
> spdadd 10.0.0.253/24 192.168.100.253/24 any -P out ipsec
>         esp/tunnel/city_one-city_two/require ;
> spdadd 192.168.100.253/24 10.0.0.253/24 any -P in ipsec
>         esp/tunnel/city_two-city-one/require ;
>
> /etc/rc.conf has this:
>
> # added 4/30/2002 for VPN to city_two
> ipsec_enable="YES"
> gif_interfaces="gif0"   # removed 11/17/2002 dmk
>
> # from here to there...
> gifconfig_gif0="city_one city_two"
> ifconfig_gif0="inet 10.0.0.253 192.168.100.253 netmask 255.255.255.255"
>
> # the VPN route:
> static_routes="city_two"
> route_city_two="-inet 192.168.100.0/24 -interface 192.168.100.253"
>
> Other than racoon, that's what it took. So why did I have to fire up
> gif0? For a while with RELENG_4 the gif entries in /etc/rc.conf were
> not needed. I have never seen any hits on my gif rules in ipfw.
>
> --
> David Kelly N4HHE, [EMAIL PROTECTED]
> =====================================================================
> The human mind ordinarily operates at only ten percent of its
> capacity -- the rest is overhead for the operating system.
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-questions" in the body of the message



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to