On Wed, Apr 13, 2011 at 02:53:29PM -0700, Matt S wrote:
> Thank you for all of the help. I am effectively giving up on doing it this
> way. OpenVPN seems to have facilities to make it easier to achieve what I
> want
> to do. I appreciate all of the time and effort spent.
>
>
There should be no difference in using OpenVPN or IPSEC, your problem is not
related to that. I'll try this again.
1. Make the VPN
2. Add a host route to the other-end external address through the local gateway.
3. Add the default gateway as the other-end VPN address.
So your tunnel will be able to reach the other side (the external host route).
Sorry but I'm a bit busy to understand your setup.
I'm sending you a script which does that.
> On Wed, 2011-04-13 at 07:34 -0700, Matt S wrote:
> > Hi Claudiu:
> >
> >
> > Thank you for your reply. I did try your suggestion to do a route add
> > A.B.C.D.E <isp gateway> and unfortunately it did not work so well. I
> > lost connectivity to the branch altogether over the VPN. At least I
> > have console access :) Once I removed the route, I regained
> > connectivity over the vpn. Perhaps, I can show you the routing
> > tables, if that will help?
> >
> >
> > Main
> > Internet:
> > Destination Gateway Flags Refs Use Mtu
> > Prio Iface
> > default phnx-dsl-gw55-247. UGS 19 1629401 -
> > 8 tun0
> > 10.40.60/24 link#1 UC 2 0 -
> > 4 em0
> > 10.40.60.3 00:24:2c:07:d4:d0 UHLc 1 3217 -
> > 4 em0
> > 10.40.60.5 link#1 UHLc 1 847 -
> > 4 em0
> > 10.40.65/24 172.16.254.2 UG 0 22 -
> > 32 gre0
> > phnx-dsl-gw55-247. 71-223-148-144.phn UH 1 12 1492
> > 4 tun0
> > loopback localhost UGRS 0 0 33200
> > 8 lo0
> > localhost localhost UH 0 60 33200
> > 4 lo0
> > 172.16.254.1/32 172.16.254.2 UG 0 0 -
> > 32 gre0
> > 172.16.254.2 172.16.254.1 UH 2 157 -
> > 4 gre0
> > BASE-ADDRESS.MCAST localhost URS 0 0 33200
> > 8 lo0
> >
> >
> > Branch
> > Destination Gateway Flags Refs Use Mtu
> > Prio Iface
> > default 206.125.169.97 UGS 3 11772 -
> > 8 em0
> > 10.40.60/24 172.16.254.1 UG 1 50 -
> > 32 gre0
> > 10.40.65/24 link#4 UC 1 0 -
> > 4 vether0
> > 10.40.65.1 fe:e1:ba:d0:da:7e UHLc 0 4 -
> > 4 lo0
> > loopback localhost UGRS 0 0 33160
> > 8 lo0
> > localhost localhost UH 1 60 33160
> > 4 lo0
> > 172.16.254.1 172.16.254.2 UH 2 87 -
> > 4 gre0
> > 172.16.254.2/32 172.16.254.1 UG 0 0 -
> > 32 gre0
> > 206.125.169.96/29 link#1 UC 2 0 -
> > 4 em0
> > 206.125.169.97 00:0d:65:ab:c8:bf UHLc 1 0 -
> > 4 em0
> > matthew-schwartz.c 52:54:00:27:26:22 UHLc 0 0 -
> > 4 lo0
> > BASE-ADDRESS.MCAST localhost URS 0 0 33160
> > 8 lo0
> >
> >
> >
> > On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
> > > Hello @misc:
> > >
> > > I am up against a stumper. I have a Site-to-Site IPSEC VPN working
> > beautifully.
> > > However, I would like the remote site to route all of its traffic
> > through the
> > > VPN. After googling, I seemed to come up with a suggestion to do a
> > route change
> > > -net 0.0.0.0/0 <gateway> which didn't work well. I think it might
> > have to do
> > > with NAT. The main office is doing the NAT. Perhaps I need to some
> > sort of NAT
> > > traversal on the VPN??
> > >
> > > Here is my setup:
> > >
> > > --Main Office--
> > > cat /etc/ipsec.conf:
> > > me="A.B.C.D"
> > > mypeer="E.F.G.H"
> > > mypsk="mypsk"
> > >
> > > ike passive esp from $me to $mypeer peer $mypeer \
> > > main auth hmac-sha1 enc 3des group modp1024 \
> > > srcid $me dstid $mypeer \
> > > psk $mypsk
> > >
> > > cat /etc/hostname.gre0:
> > > inet 172.16.254.1 255.255.255.252 172.16.254.2
> > > tunnel A.B.C.D E.F.G.H
> > > !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
> > >
> > > cat /etc/pf.conf:
> > > set skip on {lo, gre0, enc0}
> > >
> > > anchor "ftp-proxy/*"
> > >
> > > block in log all
> > > pass out all
> > >
> > > antispoof for tun0
> > > table <bruteforce> persist
> > > table <trustednets> {10.40.60.0/24, 10.40.65.0/24}
> > >
> > > match out on tun0 from <trustednets> to any nat-to (tun0)
> > >
> > > pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
> > > pass in quick proto tcp from localhost to any port {http,https}
> > rdr-to 127.0.0.1
> > > port 3128
> > > pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
> > > block log quick from <bruteforce>
> > > pass inet proto icmp all icmp-type {echoreq, unreach}
> > > pass in on tun0 inet proto tcp from any to any port ssh keep state
> > (max-src-conn
> > > 6, max-src-conn-rate 3/1, overload <bruteforce> flush global) rdr-to
> > 10.40.60.1
> > > pass on em0 from <trustednets> to any
> > >
> > >
> > > --Branch Office--
> > > cat /etc/ipsec.conf:
> > > me="E.F.G.H"
> > > mypeer="A.B.C.D"
> > > mypsk="mypsk"
> > >
> > > ike esp from $me to $mypeer peer $mypeer \
> > > main auth hmac-sha1 enc 3des group modp1024 \
> > > srcid $me dstid $mypeer \
> > > psk $mypsk
> > >
> > > cat /etc/hostname.gre0:
> > > inet 172.16.254.2 255.255.255.252 172.16.254.1
> > > tunnel E.F.G.H A.B.C.D
> > > !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1
> > >
> > > Firewall disabled for now - nothing other than sshd and isakmpd are
> > running.
> > >
> > > Thanks,
> > > Matt
> > >
> >
> > Matt
> >
> > did you put on the branch router a route like
> > route add A.B.C.D <branch isp gateway> ?
> >
> > beware that if you issue just route add default 172.16.254.1 then your
> > router will tend to also route the vpn traffic through your tunnel, so
> > you get a race condition.
> >
> > claudiu.
> >
> >
> > --
> > Claudiu Pruna
> >
> >
> >
> supposing, as I understood, yhay you want to route ALL the branch's
> traffic through vpn to main, and then on the internet, the route that I
> was saying is:
> On branch, *not* main:
>
> route add A.B.C.D 206.125.169.97
>
> is it what you did ?
>
> --
> Claudiu Pruna
--
Christiano Farina HAESBAERT
Do NOT send me html mail.
