RE: VPN problem
Hi
TUN and NG connections are not present at the time you start your server and
rules for such interfaces are not applicable to PF
The is there the if up and if down functions of MPD come into place unless
you use IP Address/network specific rules.
One server I have in the if-up script:
/etc/rc.d/pf resync
/sbin/pfctl -t if_pptp -T add ${4}
And it works perfectly fine including on the secondary MPD instance (bound
to IP address) allowing usage as default gateway functions.
Other than that I think you will have to go down the bridging line.
I may be corrected bu others :-)
Regards
Torsten
-Original Message-
From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org] On
Behalf Of Mario Lobo
Sent: 09 September 2011 22:53
To: freebsd...@freebsd.org
Cc: freebsd-questions@freebsd.org
Subject: Re: VPN problem
On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote:
> HI Mario
> I don't know what the experts are suggesting but I use a table for the VPN
> addresses
> To allow nat but block them frm using the server as gateway ("use as
> default gateway" disabled in windows)
> I add the rules dynamically using mpd if-up and if-down scripts
>
> All I have in my rules is GRE pass anywhere and nat to and from
> where ever
>
> Regards
> Torsten
>
Thanks for replying, Torsten but the problem is way before all these things
that you mentioned. I'm wildly guessing here but the problem seems to be
inside the NAT mechanism of PF. At least the working/not working situations
point to that direction.
If I don't find a solution to that soon I am gonna have no choice but to
switch to IPFW, which I would not like to do because the queuing mechanisms
of
pf are extremely useful and handy to my networks.
By the way, I also do each item that you mentioned in your post.
The funny thing is that there was a time (maybe a couple csups ago) that
this
problem didn't occur, and I am totally unable to say which csup brought this
issue in. Remeber there are 3 FBSDs involved here.
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE)
>
> -Original Message-
> From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org]
On
> Behalf Of Mario Lobo
> Sent: 09 September 2011 20:46
> To: freebsd...@freebsd.org
> Cc: freebsd-questions@freebsd.org
> Subject: VPN problem
>
> Hi;
>
> I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE
> with pf.
>
> I have this scenario:
>
>
> home LAN FBSD+pf home INTERNET --- FBSD+pf work --- work LAN
> MPD VPN server
>
> nat rules on FBSD+pf home:
>
>
> nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535
> # nat on $ext_if from any to any -> ($ext_if) port 1024:65535
>
>
> obs- it makes no difference which nat rule I use. The problem persists.
>
>
> These are the first 5 pf rules on FBSD+pf home:
>
> # pass quick all
> pass quick on lo0 all
>
> # my whole home lan is free
> pass in quick on $int_if from $int_if:network to any
>
> #--- Allow networks to see themselves and dns
> pass quick from $int_if:network to $int_if:network
>
> #--- Allow vpns from anywhere to anywhere
> pass in quick log on $int_if proto gre from any to any keep state
> pass in quick log on $int_if proto tcp from any to any port pptp flags
> S/SA
> keep state
>
>
>
> On any attempt to connect to the FBSD+pf work VPN Server from home LAN,
> I get this (even if I uncomment pass quick all):
>
> #>mpd5
> Multi-link PPP daemon for FreeBSD
>
> process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011)
> CONSOLE: listening on 127.0.0.1 5005
> web: listening on 127.0.0.1 5006
> [B1] Bundle: Interface ng0 created
> [L1] [L1] Link: OPEN event
> [L1] LCP: Open event
> [L1] LCP: state change Initial --> Starting
> [L1] LCP: LayerStart
> [L1] PPTP call successful
> [L1] Link: UP event
> [L1] LCP: Up event
> [L1] LCP: state change Starting --> Req-Sent
> [L1] LCP: SendConfigReq #1
> [L1] ACFCOMP
> [L1] PROTOCOMP
> [L1] ACCMAP 0x000a
> [L1] MRU 1486
> [L1] MAGICNUM 2d08ae01
>
> [snip..]
>
> [L1] LCP: SendConfigReq #10
> [L1] ACFCOMP
> [L1] PROTOCOMP
> [L1] ACCMAP 0x000a
> [L1] MRU 1486
> [L1] MAGICNUM 2d08ae01
> [L1] LCP: parameter negotiation failed
> [L1] LCP: state change Req-Sent --> Stopped
> [L1] LCP: LayerFinish
> [L1] PPTP call terminated
> [L1] Link: DOWN event
> [L1] LCP: Close event
> [L1] LCP: state change Stopped --> Closed
> [L1] LCP: Down event
> [L1] LCP: state change Closed
Re: VPN problem
On Friday 09 September 2011 19:03:27 Torsten Kersandt wrote:
> Hi
> TUN and NG connections are not present at the time you start your server
> and rules for such interfaces are not applicable to PF
You're right, but on the client end that is trying to conect to that server
behind a pf firewall, nat rules DO apply, and on my tests I can see for sure
that when I take NAT out of the picture, the VPN tunnel is established.
>
> The is there the if up and if down functions of MPD come into place unless
> you use IP Address/network specific rules.
> One server I have in the if-up script:
>
> /etc/rc.d/pf resync
> /sbin/pfctl -t if_pptp -T add ${4}
I do all that! in fact even go beyond and use the linkup/down scripts to
create a log on the server of which user(s) is(are) conected to the VPN, from
which public IP, with which ng interface, at what time/date they logged in and
and logged out.
>
> And it works perfectly fine including on the secondary MPD instance (bound
> to IP address) allowing usage as default gateway functions.
>
Like I said before:
"The FBSD+pf work VPN Server is working fine. My colleagues can connect to
it from their homes (NATted cable modems or 3G modems) without problems."
> Other than that I think you will have to go down the bridging line.
> I may be corrected bu others :-)
>
> Regards
> Torsten
>
Thanks again, Torsten. I think this issue seems to lie deeper that just pf
rules and link scripts
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE)
>
> -Original Message-
> From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org] On
> Behalf Of Mario Lobo
> Sent: 09 September 2011 22:53
> To: freebsd...@freebsd.org
> Cc: freebsd-questions@freebsd.org
> Subject: Re: VPN problem
>
> On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote:
> > HI Mario
> > I don't know what the experts are suggesting but I use a table for the
> > VPN addresses
> > To allow nat but block them frm using the server as gateway ("use as
> > default gateway" disabled in windows)
> > I add the rules dynamically using mpd if-up and if-down scripts
> >
> > All I have in my rules is GRE pass anywhere and nat to and from
> > where ever
> >
> > Regards
> > Torsten
>
> Thanks for replying, Torsten but the problem is way before all these things
> that you mentioned. I'm wildly guessing here but the problem seems to be
> inside the NAT mechanism of PF. At least the working/not working situations
> point to that direction.
>
> If I don't find a solution to that soon I am gonna have no choice but to
> switch to IPFW, which I would not like to do because the queuing mechanisms
> of
> pf are extremely useful and handy to my networks.
>
> By the way, I also do each item that you mentioned in your post.
>
> The funny thing is that there was a time (maybe a couple csups ago) that
> this
> problem didn't occur, and I am totally unable to say which csup brought
> this
>
> issue in. Remeber there are 3 FBSDs involved here.
>
> > -Original Message-
> > From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org]
>
> On
>
> > Behalf Of Mario Lobo
> > Sent: 09 September 2011 20:46
> > To: freebsd...@freebsd.org
> > Cc: freebsd-questions@freebsd.org
> > Subject: VPN problem
> >
> > Hi;
> >
> > I've been having this problem establishing a VPN behind a FreeBSD
> > 8-STABLE with pf.
> >
> > I have this scenario:
> >
> >
> > home LAN FBSD+pf home INTERNET --- FBSD+pf work --- work LAN
> >
> > MPD VPN server
> >
> > nat rules on FBSD+pf home:
> > nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535
> > # nat on $ext_if from any to any -> ($ext_if) port 1024:65535
> >
> > obs- it makes no difference which nat rule I use. The problem persists.
> >
> > These are the first 5 pf rules on FBSD+pf home:
> > # pass quick all
> > pass quick on lo0 all
> >
> > # my whole home lan is free
> > pass in quick on $int_if from $int_if:network to any
> >
> > #--- Allow networks to see themselves and dns
> > pass quick from $int_if:network to $int_if:network
> >
> > #--- Allow vpns from anywhere to anywhere
> > pass in quick log on $int_if proto gre from any to any keep state
> > pass in quick log on $int_if proto tcp from any to any port pptp flags
> >
> > S/SA
> > keep stat
Re: VPN problem
On Friday 09 September 2011 18:11:47 Torsten Kersandt wrote:
> HI Mario
> I don't know what the experts are suggesting but I use a table for the VPN
> addresses
> To allow nat but block them frm using the server as gateway ("use as
> default gateway" disabled in windows)
> I add the rules dynamically using mpd if-up and if-down scripts
>
> All I have in my rules is GRE pass anywhere and nat to and from
> where ever
>
> Regards
> Torsten
>
Thanks for replying, Torsten but the problem is way before all these things
that you mentioned. I'm wildly guessing here but the problem seems to be
inside the NAT mechanism of PF. At least the working/not working situations
point to that direction.
If I don't find a solution to that soon I am gonna have no choice but to
switch to IPFW, which I would not like to do because the queuing mechanisms of
pf are extremely useful and handy to my networks.
By the way, I also do each item that you mentioned in your post.
The funny thing is that there was a time (maybe a couple csups ago) that this
problem didn't occur, and I am totally unable to say which csup brought this
issue in. Remeber there are 3 FBSDs involved here.
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE)
>
> -Original Message-
> From: owner-freebsd...@freebsd.org [mailto:owner-freebsd...@freebsd.org] On
> Behalf Of Mario Lobo
> Sent: 09 September 2011 20:46
> To: freebsd...@freebsd.org
> Cc: freebsd-questions@freebsd.org
> Subject: VPN problem
>
> Hi;
>
> I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE
> with pf.
>
> I have this scenario:
>
>
> home LAN FBSD+pf home INTERNET --- FBSD+pf work --- work LAN
> MPD VPN server
>
> nat rules on FBSD+pf home:
>
>
> nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535
> # nat on $ext_if from any to any -> ($ext_if) port 1024:65535
>
>
> obs- it makes no difference which nat rule I use. The problem persists.
>
>
> These are the first 5 pf rules on FBSD+pf home:
>
> # pass quick all
> pass quick on lo0 all
>
> # my whole home lan is free
> pass in quick on $int_if from $int_if:network to any
>
> #--- Allow networks to see themselves and dns
> pass quick from $int_if:network to $int_if:network
>
> #--- Allow vpns from anywhere to anywhere
> pass in quick log on $int_if proto gre from any to any keep state
> pass in quick log on $int_if proto tcp from any to any port pptp flags
> S/SA
> keep state
>
>
>
> On any attempt to connect to the FBSD+pf work VPN Server from home LAN,
> I get this (even if I uncomment pass quick all):
>
> #>mpd5
> Multi-link PPP daemon for FreeBSD
>
> process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011)
> CONSOLE: listening on 127.0.0.1 5005
> web: listening on 127.0.0.1 5006
> [B1] Bundle: Interface ng0 created
> [L1] [L1] Link: OPEN event
> [L1] LCP: Open event
> [L1] LCP: state change Initial --> Starting
> [L1] LCP: LayerStart
> [L1] PPTP call successful
> [L1] Link: UP event
> [L1] LCP: Up event
> [L1] LCP: state change Starting --> Req-Sent
> [L1] LCP: SendConfigReq #1
> [L1] ACFCOMP
> [L1] PROTOCOMP
> [L1] ACCMAP 0x000a
> [L1] MRU 1486
> [L1] MAGICNUM 2d08ae01
>
> [snip..]
>
> [L1] LCP: SendConfigReq #10
> [L1] ACFCOMP
> [L1] PROTOCOMP
> [L1] ACCMAP 0x000a
> [L1] MRU 1486
> [L1] MAGICNUM 2d08ae01
> [L1] LCP: parameter negotiation failed
> [L1] LCP: state change Req-Sent --> Stopped
> [L1] LCP: LayerFinish
> [L1] PPTP call terminated
> [L1] Link: DOWN event
> [L1] LCP: Close event
> [L1] LCP: state change Stopped --> Closed
> [L1] LCP: Down event
> [L1] LCP: state change Closed --> Initial
>
>
> BUT, on the 9th or 10th attempt, without touching any setting anywhere, the
> VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever)
> behind both FBSD+pfs ALSO have the same problem when trying to close VPN
> tunnels to outside sites.
>
> Sometimes, opening an ssh session from my workstation to FBSD+pf work may
> "help" in establishing the VPN.
>
> The FBSD+pf work VPN Server is working fine. My colleagues can connect to
> it
>
> from their homes (NATted cable modems or 3G modems) without problems. I am
> the
> only one behind a FBSD+pf router.
>
>
> I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home
> workstation
> to it.
>
>
> Without touching a single setting on mpd.conf, the VPN is established
VPN problem
Hi; I've been having this problem closing a VPN behind a FreeBSD 8-STABLE with pf. I have this scenario: home LAN FBSD+pf home INTERNET --- FBSD+pf work --- work LAN MPD VPN server nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 obs- it makes no difference which nat rule I use. The problem persists. These are the first 5 pf rules on FBSD+pf home: # pass quick all pass quick on lo0 all # my whole home lan is free pass in quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network #--- Allow vpns from anywhere to anywhere pass in quick log on $int_if proto gre from any to any keep state pass in quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state On any attempt to conect to the FBSD+pf work VPN Server from home LAN, I get this (even if I uncomment pass quick all): #>mpd5 Multi-link PPP daemon for FreeBSD process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) CONSOLE: listening on 127.0.0.1 5005 web: listening on 127.0.0.1 5006 [B1] Bundle: Interface ng0 created [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] Link: UP event [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [snip..] [L1] LCP: SendConfigReq #10 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [L1] LCP: parameter negotiation failed [L1] LCP: state change Req-Sent --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Close event [L1] LCP: state change Stopped --> Closed [L1] LCP: Down event [L1] LCP: state change Closed --> Initial BUT, on the 9th or 10th attempt, without touching any setting anywhere, the VPN MAY BE established. out of nothing ! Machines (Windows, unix, whatever) behind both FBSD+pfs ALSO have the same problem when trying to close VPN tunnels to outside sites. The FBSD+pf work VPN Server is working fine. My coleagues can conect to it from their homes (NATted cable modems or 3G modems) without problems. I am the only one behind a FBSD+pf router. I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home workstation to it. Without touching a single setting on mpd.conf, the VPN is established from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hickups on EVERY SINGLE attempt! even I bring it up/down 200 times! And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the case of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, the problem is GONE!. FreeBSD work FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 FreeBSD Home FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 Any suggestions? -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
VPN problem
Hi; I've been having this problem establishing a VPN behind a FreeBSD 8-STABLE with pf. I have this scenario: home LAN FBSD+pf home INTERNET --- FBSD+pf work --- work LAN MPD VPN server nat rules on FBSD+pf home: nat on $ext_if from $int_if:network to any -> ($ext_if) port 1024:65535 # nat on $ext_if from any to any -> ($ext_if) port 1024:65535 obs- it makes no difference which nat rule I use. The problem persists. These are the first 5 pf rules on FBSD+pf home: # pass quick all pass quick on lo0 all # my whole home lan is free pass in quick on $int_if from $int_if:network to any #--- Allow networks to see themselves and dns pass quick from $int_if:network to $int_if:network #--- Allow vpns from anywhere to anywhere pass in quick log on $int_if proto gre from any to any keep state pass in quick log on $int_if proto tcp from any to any port pptp flags S/SA keep state On any attempt to connect to the FBSD+pf work VPN Server from home LAN, I get this (even if I uncomment pass quick all): #>mpd5 Multi-link PPP daemon for FreeBSD process 98799 started, version 5.5 (root@Papi 16:55 3-Sep-2011) CONSOLE: listening on 127.0.0.1 5005 web: listening on 127.0.0.1 5006 [B1] Bundle: Interface ng0 created [L1] [L1] Link: OPEN event [L1] LCP: Open event [L1] LCP: state change Initial --> Starting [L1] LCP: LayerStart [L1] PPTP call successful [L1] Link: UP event [L1] LCP: Up event [L1] LCP: state change Starting --> Req-Sent [L1] LCP: SendConfigReq #1 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [snip..] [L1] LCP: SendConfigReq #10 [L1] ACFCOMP [L1] PROTOCOMP [L1] ACCMAP 0x000a [L1] MRU 1486 [L1] MAGICNUM 2d08ae01 [L1] LCP: parameter negotiation failed [L1] LCP: state change Req-Sent --> Stopped [L1] LCP: LayerFinish [L1] PPTP call terminated [L1] Link: DOWN event [L1] LCP: Close event [L1] LCP: state change Stopped --> Closed [L1] LCP: Down event [L1] LCP: state change Closed --> Initial BUT, on the 9th or 10th attempt, without touching any setting anywhere, the VPN MAY BE established. out of nothing ! Machines (Windows, Unix, whatever) behind both FBSD+pfs ALSO have the same problem when trying to close VPN tunnels to outside sites. Sometimes, opening an ssh session from my workstation to FBSD+pf work may "help" in establishing the VPN. The FBSD+pf work VPN Server is working fine. My colleagues can connect to it from their homes (NATted cable modems or 3G modems) without problems. I am the only one behind a FBSD+pf router. I installed MPD5 on FBSD+pf home, and copied mpd.conf from my home workstation to it. Without touching a single setting on mpd.conf, the VPN is established from FBSD+pf home (as a client) to FBSD+pf work WITHOUT any hiccups on EVERY SINGLE attempt! even I bring it up/down 200 times! And yet, if the FBSD+pf combo is out of the way, (i.e. no NAT!, as is the case of FBSD+pf home as a client) or if I let my cable modem do the NAT/routing, the problem is GONE!. FreeBSD work FreeBSD 8.2-STABLE #0: Mon Aug 22 14:50:42 BRT 2011 amd64 FreeBSD Home FreeBSD FreeBSD 8.2-STABLE #0: Wed May 18 16:53:26 BRT 2011 i386 Any suggestions? Thanks, -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: pptpclient vpn problem
Hello, I have been having the same problems with pptp trying to connect to a Win VPN server. Could not figure out what the problem was. I guess it had something to do with the encryption protocols. I am currently using mpd. You can find it in the ports tree. There are some sample conf files on the net too. Good Luck. Ivan Georgiev On Fri, 5 Jan 2007 01:53:04 +0200 Clickety <[EMAIL PROTECTED]> wrote: > Hello! > > I have a problem setting up VPN connection to my workplace. > > I followed this tutorial http://www.freebsddiary.org/pptp.php > > When i start pptp client it looks like the connection is created. > I get an ip address on tun0. Routes are added to the routing table and > everything seems fine. > But when i try to connect/ping to any server through the vpn, the > connection closes. > This vpn connection works from my XP box with no problems. > > /etc/ppp/ppp.conf > > WORK: > set authname myusername > set authkey mypass > set timeout 0 > set ifaddr 0 0 > add 192.168.100.0/24 HISADDR > alias enable yes > disable ipv6cp > > > /var/log/ppp.log > > Jan 4 22:49:33 bsd ppp[7376]: Phase: Using interface: tun0 > Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: Created in closed state > Jan 4 22:49:33 bsd ppp[7376]: Warning: The alias command is deprecated > Jan 4 22:49:33 bsd ppp[7376]: Phase: PPP Started (direct mode). > Jan 4 22:49:33 bsd ppp[7376]: Phase: bundle: Establish > Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: closed -> opening > Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: Connected! > Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: opening -> carrier > Jan 4 22:49:34 bsd ppp[7376]: Phase: deflink: carrier -> lcp > Jan 4 22:49:36 bsd ppp[7376]: Phase: bundle: Authenticate > Jan 4 22:49:36 bsd ppp[7376]: Phase: deflink: his = CHAP 0x81, mine = none > Jan 4 22:49:36 bsd ppp[7376]: Phase: Chap Input: CHALLENGE (16 bytes from gw) > Jan 4 22:49:36 bsd ppp[7376]: Phase: Chap Output: RESPONSE (user) > Jan 4 22:49:37 bsd ppp[7376]: Phase: Chap Input: SUCCESS > (S=F35FEFF020584E1B747EC208F7B6BF59148D5CBF) > Jan 4 22:49:37 bsd ppp[7376]: Phase: deflink: lcp -> open > Jan 4 22:49:37 bsd ppp[7376]: Phase: bundle: Network > Jan 4 22:49:44 bsd ppp[7376]: Phase: deflink: open -> lcp > Jan 4 22:49:44 bsd ppp[7376]: Phase: bundle: Terminate > Jan 4 22:49:44 bsd ppp[7376]: Phase: Signal 15, terminate. > Jan 4 22:49:44 bsd ppp[7376]: Phase: Signal 15, terminate. > Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: Disconnected! > Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: Connect time: 14 secs: > 584 octets in, 776 octets out > Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: 15 packets in, 17 packets out > Jan 4 22:49:47 bsd ppp[7376]: Phase: total 97 bytes/sec, peak 202 > bytes/sec on Thu Jan 4 22:49:38 2007 > Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: lcp -> closed > Jan 4 22:49:47 bsd ppp[7376]: Phase: bundle: Dead > Jan 4 22:49:47 bsd ppp[7376]: Phase: PPP Terminated (normal). > > > /var/log/messages > Jan 4 22:49:31 bsd pptp[7376]: anon log[main:pptp.c:267]: The > synchronous pptp option is NOT activated > Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_rep:pptp_ctrl.c:251]: > Sent control packet type is 1 'Start-Control-Connection-Request' > Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:740]: > Received Start Control Connection Reply > Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:774]: > Client connection established. > Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_rep:pptp_ctrl.c:251]: > Sent control packet type is 7 'Outgoing-Call-Request' > Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:859]: > Received Outgoing Call Reply. > Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:898]: > Outgoing call established (call ID 0, peer's call ID 140). > Jan 4 22:49:33 bsd ppp[7376]: Warning: The alias command is deprecated > Jan 4 22:49:35 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 0 > Jan 4 22:49:35 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 1 > Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 2 > Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 3 > Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 4 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 5 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 6 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 7 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 8 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 9 > Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting packet 10 > Jan 4 22:49:38 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: > accepting
pptpclient vpn problem
Hello! I have a problem setting up VPN connection to my workplace. I followed this tutorial http://www.freebsddiary.org/pptp.php When i start pptp client it looks like the connection is created. I get an ip address on tun0. Routes are added to the routing table and everything seems fine. But when i try to connect/ping to any server through the vpn, the connection closes. This vpn connection works from my XP box with no problems. /etc/ppp/ppp.conf WORK: set authname myusername set authkey mypass set timeout 0 set ifaddr 0 0 add 192.168.100.0/24 HISADDR alias enable yes disable ipv6cp /var/log/ppp.log Jan 4 22:49:33 bsd ppp[7376]: Phase: Using interface: tun0 Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: Created in closed state Jan 4 22:49:33 bsd ppp[7376]: Warning: The alias command is deprecated Jan 4 22:49:33 bsd ppp[7376]: Phase: PPP Started (direct mode). Jan 4 22:49:33 bsd ppp[7376]: Phase: bundle: Establish Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: closed -> opening Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: Connected! Jan 4 22:49:33 bsd ppp[7376]: Phase: deflink: opening -> carrier Jan 4 22:49:34 bsd ppp[7376]: Phase: deflink: carrier -> lcp Jan 4 22:49:36 bsd ppp[7376]: Phase: bundle: Authenticate Jan 4 22:49:36 bsd ppp[7376]: Phase: deflink: his = CHAP 0x81, mine = none Jan 4 22:49:36 bsd ppp[7376]: Phase: Chap Input: CHALLENGE (16 bytes from gw) Jan 4 22:49:36 bsd ppp[7376]: Phase: Chap Output: RESPONSE (user) Jan 4 22:49:37 bsd ppp[7376]: Phase: Chap Input: SUCCESS (S=F35FEFF020584E1B747EC208F7B6BF59148D5CBF) Jan 4 22:49:37 bsd ppp[7376]: Phase: deflink: lcp -> open Jan 4 22:49:37 bsd ppp[7376]: Phase: bundle: Network Jan 4 22:49:44 bsd ppp[7376]: Phase: deflink: open -> lcp Jan 4 22:49:44 bsd ppp[7376]: Phase: bundle: Terminate Jan 4 22:49:44 bsd ppp[7376]: Phase: Signal 15, terminate. Jan 4 22:49:44 bsd ppp[7376]: Phase: Signal 15, terminate. Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: Disconnected! Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: Connect time: 14 secs: 584 octets in, 776 octets out Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: 15 packets in, 17 packets out Jan 4 22:49:47 bsd ppp[7376]: Phase: total 97 bytes/sec, peak 202 bytes/sec on Thu Jan 4 22:49:38 2007 Jan 4 22:49:47 bsd ppp[7376]: Phase: deflink: lcp -> closed Jan 4 22:49:47 bsd ppp[7376]: Phase: bundle: Dead Jan 4 22:49:47 bsd ppp[7376]: Phase: PPP Terminated (normal). /var/log/messages Jan 4 22:49:31 bsd pptp[7376]: anon log[main:pptp.c:267]: The synchronous pptp option is NOT activated Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:740]: Received Start Control Connection Reply Jan 4 22:49:32 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:774]: Client connection established. Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:859]: Received Outgoing Call Reply. Jan 4 22:49:33 bsd pptp[7379]: anon log[ctrlp_disp:pptp_ctrl.c:898]: Outgoing call established (call ID 0, peer's call ID 140). Jan 4 22:49:33 bsd ppp[7376]: Warning: The alias command is deprecated Jan 4 22:49:35 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 0 Jan 4 22:49:35 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 1 Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 2 Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 3 Jan 4 22:49:36 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 4 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 5 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 6 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 7 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 8 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 9 Jan 4 22:49:37 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 10 Jan 4 22:49:38 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 11 Jan 4 22:49:38 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 12 Jan 4 22:49:38 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 13 Jan 4 22:49:44 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 14 Jan 4 22:49:44 bsd pptp[7380]: anon log[decaps_gre:pptp_gre.c:388]: accepting packet 15 Jan 4 22:49:44 bsd pptp[7379]: anon log[pptp_read_some:pptp_ctrl.c:545]: read returned zero, peer has closed Jan 4 22:49:44 bsd pptp[7379]: anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown) Jan 4 22:49:44 bsd pptp[7379]:
Re: Racoon / VPN problem
That looks a bit like mine too.. (this output taken from host .14.1) Of course these would be reversed on 14.2 ie, the in and out bits) 192.168.14.2[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/192.168.14.2-192.168.14.1/require spid=1 seq=1 pid=42486 refcnt=1 0.0.0.0/0[any] 192.168.14.2[any] any out ipsec esp/tunnel/192.168.14.1-192.168.14.2/require spid=2 seq=0 pid=42486 refcnt=1 I'm using this to IPSEC my wireless traffic. Works a treat coupled with racoon. ajt. On Fri, 2003-07-11 at 05:12, Company 2210 wrote: > I have two freebsd 5.0 boxes authenticating at stage one of the VPN, however stage 2 > fails. with: > > ph2begin_r(): respond new phase 2 negotiation: 10.0.0.1[0]<=>10.0.0.2[0] > get_proposal_r(): no policy found: 10.0.0.2/32[0] 0.0.0.0/0[0] proto=any dir=in > quick_r1recv(): failed to get proposal for responder. > _ph2begin_r(): failed to pre-process packet. > > I'm a bit new too this, so I'm guessing the lack of a policy refers to my SPD > Database. Setkey -DP looks like this: > > 0.0.0.0/0[any] 10.0.0.1[any] any > in ipsec > esp/tunnel/10.0.0.2-10.0.0.1/require > spid=19 seq=1 pid=770 > refcnt=1 > > 10.0.0.1[any] 0.0.0.0/0[any] any > out ipsec > esp/tunnel/10.0.0.1-10.0.0.2/require > spid=18 seq=0 pid=770 > refcnt=1 > > As I understand it, this means all packets heading too or from 10.0.0.1 must be > encapsulated (which is what I want, as I'm running a VPN between too FreeBSD gateway > boxes). If I replace the 0.0.0.0/0 with the IP of the other boxes inteface (i.e. > 10.0.0.2) the VPN works between 10.0.0.1<->10.0.0.2, but other traffic from other > interfaces is not encrypted. Any help in resolving/understanding this issue is > greatly appericated. > > Many Thanks > > Colin > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Racoon / VPN problem
I have two freebsd 5.0 boxes authenticating at stage one of the VPN, however stage 2 fails. with: ph2begin_r(): respond new phase 2 negotiation: 10.0.0.1[0]<=>10.0.0.2[0] get_proposal_r(): no policy found: 10.0.0.2/32[0] 0.0.0.0/0[0] proto=any dir=in quick_r1recv(): failed to get proposal for responder. _ph2begin_r(): failed to pre-process packet. I'm a bit new too this, so I'm guessing the lack of a policy refers to my SPD Database. Setkey -DP looks like this: 0.0.0.0/0[any] 10.0.0.1[any] any in ipsec esp/tunnel/10.0.0.2-10.0.0.1/require spid=19 seq=1 pid=770 refcnt=1 10.0.0.1[any] 0.0.0.0/0[any] any out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require spid=18 seq=0 pid=770 refcnt=1 As I understand it, this means all packets heading too or from 10.0.0.1 must be encapsulated (which is what I want, as I'm running a VPN between too FreeBSD gateway boxes). If I replace the 0.0.0.0/0 with the IP of the other boxes inteface (i.e. 10.0.0.2) the VPN works between 10.0.0.1<->10.0.0.2, but other traffic from other interfaces is not encrypted. Any help in resolving/understanding this issue is greatly appericated. Many Thanks Colin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
