Re: mutiple pptp pass-through PF
On 23:11:21 Nov 23, Girish Venkatachalam wrote: > > I am working on it. I plan to spend the whole night hacking it. > > My diff is old and is not coded as per style(9). > > So I am reworking it and also generating a diff against -current. > > Please wait for an update from me within the next 48 hours. > Please pardon the delay. I just sent the diff to [EMAIL PROTECTED] Please test it. Thanks. regards, Girish
Re: mutiple pptp pass-through PF
On 15:48:37 Nov 23, Andre Ruppert wrote: > A short "user's view" from a simple OBSD user: > > Pptp is a security risk, d'accord. > > But here in Germany, a lot of H.323-VoIP-systems (gates and clients) > work with pptp tunneling to be independent from H.323-NAT on firewalls. > > The corresponding dual-homed VoIP-gateways accept pptp from their > VoIP-Clients in different locations. Ipsec stacks are not supportet. > > So, at least H.323 VoIP technology would appreciate this diff :-) I am working on it. I plan to spend the whole night hacking it. My diff is old and is not coded as per style(9). So I am reworking it and also generating a diff against -current. Please wait for an update from me within the next 48 hours. Thanks. regards, Girish
Re: mutiple pptp pass-through PF
A short "user's view" from a simple OBSD user: Pptp is a security risk, d'accord. But here in Germany, a lot of H.323-VoIP-systems (gates and clients) work with pptp tunneling to be independent from H.323-NAT on firewalls. The corresponding dual-homed VoIP-gateways accept pptp from their VoIP-Clients in different locations. Ipsec stacks are not supportet. So, at least H.323 VoIP technology would appreciate this diff :-) Greetings Andre Ruppert
Re: mutiple pptp pass-through PF
On Thu, Nov 22, 2007 at 08:39:43PM +0530, Raja Subramanian wrote: > On 11/22/07, Girish Venkatachalam <[EMAIL PROTECTED]> wrote: > > Here is a promise. You shall have the patch from me sent to tech@ before > > Dec 15. > > Wow! :-) > > Every time I hit the pptp limitation, I start coding and a few hours later > give up in disgust. Over many sittings, I've nearly completed the > userland pptp-proxy, and started on hacking the kernel pf to do a full > NAT on GRE using Call-IDs (in place of tcp/udp port numbers). I have > not tested the kernel bit, but the userland stuff works okay. > this sound like a better approach, it could make sense to handle just the GRE call-ids in the kernel and the pptp handling in userland. but if the overhead is low enough or the GRE code too complex, it is even better to do everything in userland... > I even started http://sourceforge.net/projects/pptp-proxy, and later > abandoned it. The sourceforge code is ancient, don't use it, the latest > work was never committed. > > Let me know if you want any of my code. > yes, please > Should you decide to go with the userland pptp-proxy approach, it's > important to know that there's a bug in 4.2 that triggers a kernel dump > whenever you call pf ioctl PFIOCADDSTATE with bad args. A fix for > this is available, but I doubt if its worked itself into CURRENT. > > - Raja > reyk
Re: mutiple pptp pass-through PF
Beavis wrote: > ... as soon as everybody is > moved here we can easily let this pptp go... Much relieved to know that.
Re: mutiple pptp pass-through PF
On 14:40:57 Nov 22, Henning Brauer wrote: > sounds reasonable. but i have no idea how coplicated gre is or what it > takes to translate callIDs. Take a look at my diff. I have already done all the work for you. The only advantage with my design is the ease with which you can get it working. No config changes, no userland stuff, no redirection, no overhead, nothing. The problem however is that something tells me deep inside my heart that somewhere something is wrong. :) You are the best judge. Awaiting your speedy reply. regards, Girish
Re: mutiple pptp pass-through PF
On 13:34:22 Nov 22, Stuart Henderson wrote:
> it must look at the control message on TCP/1723 and translate CallID;
Modulate, not translate. :) My terminology.
I am using arc4random() to generate unique callIDs that do not clash.
The callID is always set to zero by PPTP , hence this requirement.
( No more comments about M$ stuff :)
> then it must look at the session packets (GRE/proto 47) and translate
> CallID the same way.
Yes and maintain a mapping.
This is far more difficult than it first appears. You can see the diff
for what all needs to be done.
>
> the parts handling control messages probably belong in userland and
> they can add translation rules to an anchor like ftp-proxy does, but
> that would need a change to PF so that you can tell it to translate
> CallID for GRE packets (like you can tell it to translate port for
> TCP/UDP).
>
> http://blogs.isaserver.org/pouseele/2007/06/17/multiple-pptp-vpn-clients-behind-a-nat-device/
I think though it takes a lot of clever programming and even
smarter design, I have a problem with maintaining the table in kernel. I
got it working perfectly a long time ago ( roughly a year ago) and I can
send the working diff right away if you want.
I am sure Henning is not going to like it. :)
Whether it is small or not is a matter of taste but if I were to do it
correctly I will do it the proxy rdr way.
The problem however with that approach is that there is a huge overhead
in passing packets between kernel to userland and back.
Here is the diff attached. If you like it commit it. :)
And bear in mind that I developed it against old code, so you might have
to do some tweaks.
If not I am more than willing to do it the right way.
Let me know your choice.
regards,
Girish
Index: pfvar.h
===
RCS file: /cvs/src/sys/net/pfvar.h,v
retrieving revision 1.242
diff -c -r1.242 pfvar.h
*** pfvar.h 13 Dec 2006 05:10:15 - 1.242
--- pfvar.h 12 Mar 2007 09:18:49 -
***
*** 2,7
--- 2,8
/*
* Copyright (c) 2001 Daniel Hartmeier
+ * Copyright (c) 2007 Girish Venkatachalam
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
***
*** 936,941
--- 937,943
struct tcphdr *tcp;
struct udphdr *udp;
struct icmp *icmp;
+ struct gre_h *gre;
#ifdef INET6
struct icmp6_hdr*icmp6;
#endif /* INET6 */
***
*** 958,963
--- 960,970
sa_family_t af;
u_int8_t proto;
u_int8_t tos;
+ u_int16_tmycallid; /* PPTP lan call id */
+ u_int16_tpeercallid;/* PPTP remote call id */
+ struct pfpptp_head *pptph;
+
+
};
/* flags for RDR options */
***
*** 1351,1356
--- 1358,1372
int pfiio_size;
int pfiio_nzero;
int pfiio_flags;
+ };
+
+
+ enum { PF_PPTP_MYID, PF_PPTP_PEERID };
+
+ struct pfpptp_call {
+ SLIST_ENTRY(pfpptp_call) next_call;
+ u_int16_t myid;
+ u_int16_t peerid;
};
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.523
diff -c -r1.523 pf.c
*** pf.c22 Dec 2006 13:24:52 - 1.523
--- pf.c12 Mar 2007 09:18:01 -
***
*** 3,8
--- 3,9
/*
* Copyright (c) 2001 Daniel Hartmeier
* Copyright (c) 2002,2003 Henning Brauer
+ * Copyright (c) 2007, Girish Venkatachalam
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
***
*** 72,77
--- 73,79
#include
#include
+ #include
#include
#include
#include
***
*** 105,110
--- 107,114
intaltqs_inactive_open;
u_int32_t ticket_pabuf;
+ SLIST_HEAD(pfpptp_head,pfpptp_call) pf_pptph;
+
struct pf_anchor_stackframe {
struct pf_ruleset *rs;
struct pf_rule *r;
***
*** 163,168
--- 167,176
int, struct pfi_kif *, struct mbuf *, int,
void *, struct pf_pdesc *, struct pf_rule **,
struct pf_ruleset **, struct ifqueue *);
+ int pf_test_gre_pptp(struct pf_rule **, struct pf_state
**,
+ int , struct pfi_kif *, struct mbuf *, int,
+ void *, struct pf_pdesc *, struct pf_rule **,
+ struct pf_ruleset **, struct ifqueue *);
intpf_test_other(struct pf_rule **, struct pf_state **,
int, struct pfi_kif *, struct mbuf *, int, void *
Re: mutiple pptp pass-through PF
On 11/22/07, Girish Venkatachalam <[EMAIL PROTECTED]> wrote: > Here is a promise. You shall have the patch from me sent to tech@ before > Dec 15. Wow! :-) Every time I hit the pptp limitation, I start coding and a few hours later give up in disgust. Over many sittings, I've nearly completed the userland pptp-proxy, and started on hacking the kernel pf to do a full NAT on GRE using Call-IDs (in place of tcp/udp port numbers). I have not tested the kernel bit, but the userland stuff works okay. I even started http://sourceforge.net/projects/pptp-proxy, and later abandoned it. The sourceforge code is ancient, don't use it, the latest work was never committed. Let me know if you want any of my code. Should you decide to go with the userland pptp-proxy approach, it's important to know that there's a bug in 4.2 that triggers a kernel dump whenever you call pf ioctl PFIOCADDSTATE with bad args. A fix for this is available, but I doubt if its worked itself into CURRENT. - Raja
Re: mutiple pptp pass-through PF
On 13:04:56 Nov 22, Reyk Floeter wrote: > i'm sure that somebody told you about the reason to reject these patches: > > it does not belong into the kernel! > > write a userland proxy. > > like ftp-proxy, tftp-proxy, hoststated, ... Sure. > > how hard is it to understand? > It sure isn't. > there are zillions of insane features in linux but we don't care - it > is not the OpenBSD way of doing it. they do string operations like SIP > parsing (which looks like HTTP) in the kernel. so what? > A million thanks for your kind advice. Here is a promise. You shall have the patch from me sent to tech@ before Dec 15. A lot of poor souls have been asking this feature for years and a lot of sweat and blood has gone into my writing it. So I better try my best to get it accepted into mainline pf at the earliest. Thanks. regards, Girish
Re: mutiple pptp pass-through PF
* Stuart Henderson <[EMAIL PROTECTED]> [2007-11-22 14:38]: > On 2007/11/22 14:04, Henning Brauer wrote: > > * Reyk Floeter <[EMAIL PROTECTED]> [2007-11-22 13:11]: > > > On Tue, Nov 20, 2007 at 08:06:39PM +0530, Girish Venkatachalam wrote: > > > > pf(4) can do this. I have a diff with me but if I send it in the present > > > > state, then Theo will catch my neck. :) > > > > > > > > I should be able to submit a diff soon. I need to modify it to meet the > > > > high standards of OpenBSD... > > > > > > > > > > i'm sure that somebody told you about the reason to reject these patches: > > > > > > it does not belong into the kernel! > > > > well. depends. if it is reasonably small and obvious it might be ok. > > it must look at the control message on TCP/1723 and translate CallID; > then it must look at the session packets (GRE/proto 47) and translate > CallID the same way. > > the parts handling control messages probably belong in userland and > they can add translation rules to an anchor like ftp-proxy does, but > that would need a change to PF so that you can tell it to translate > CallID for GRE packets (like you can tell it to translate port for > TCP/UDP). sounds reasonable. but i have no idea how coplicated gre is or what it takes to translate callIDs. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: mutiple pptp pass-through PF
On 2007/11/22 14:04, Henning Brauer wrote: > * Reyk Floeter <[EMAIL PROTECTED]> [2007-11-22 13:11]: > > On Tue, Nov 20, 2007 at 08:06:39PM +0530, Girish Venkatachalam wrote: > > > pf(4) can do this. I have a diff with me but if I send it in the present > > > state, then Theo will catch my neck. :) > > > > > > I should be able to submit a diff soon. I need to modify it to meet the > > > high standards of OpenBSD... > > > > > > > i'm sure that somebody told you about the reason to reject these patches: > > > > it does not belong into the kernel! > > well. depends. if it is reasonably small and obvious it might be ok. it must look at the control message on TCP/1723 and translate CallID; then it must look at the session packets (GRE/proto 47) and translate CallID the same way. the parts handling control messages probably belong in userland and they can add translation rules to an anchor like ftp-proxy does, but that would need a change to PF so that you can tell it to translate CallID for GRE packets (like you can tell it to translate port for TCP/UDP). http://blogs.isaserver.org/pouseele/2007/06/17/multiple-pptp-vpn-clients-behind-a-nat-device/
Re: mutiple pptp pass-through PF
* Reyk Floeter <[EMAIL PROTECTED]> [2007-11-22 13:11]: > On Tue, Nov 20, 2007 at 08:06:39PM +0530, Girish Venkatachalam wrote: > > pf(4) can do this. I have a diff with me but if I send it in the present > > state, then Theo will catch my neck. :) > > > > I should be able to submit a diff soon. I need to modify it to meet the > > high standards of OpenBSD... > > > > i'm sure that somebody told you about the reason to reject these patches: > > it does not belong into the kernel! well. depends. if it is reasonably small and obvious it might be ok. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: mutiple pptp pass-through PF
On Tue, Nov 20, 2007 at 08:06:39PM +0530, Girish Venkatachalam wrote: > pf(4) can do this. I have a diff with me but if I send it in the present > state, then Theo will catch my neck. :) > > I should be able to submit a diff soon. I need to modify it to meet the > high standards of OpenBSD... > i'm sure that somebody told you about the reason to reject these patches: it does not belong into the kernel! write a userland proxy. like ftp-proxy, tftp-proxy, hoststated, ... how hard is it to understand? there are zillions of insane features in linux but we don't care - it is not the OpenBSD way of doing it. they do string operations like SIP parsing (which looks like HTTP) in the kernel. so what? reyk
Re: mutiple pptp pass-through PF
On 07:28:05 Nov 20, Beavis wrote: > lars, > > thanks for the reply. as for the pptp implementation, I just wanted > to make PF do this (pass-through) like what other packet filtering > (iptables, even PIX) can do. I know how unsafe this implementation is, > but the site where we are currently getting this pptp connection to, > is an old branch office and i don't manage their network. they are > moving to the new facility where i have my pf firewalls in place, they > need this pptp pass-through during transition as soon as everybody is > moved here we can easily let this pptp go. on the other side of things > it would be nice to make PF do this pptp pass through, it makes pf > more of a over-all packet filter that can basically do "anything" > > and personally .. it may sound like a joke here but .. with all of > pf's features .. i kinda envy crappy routers like LINKSYS that can do > PPTP pass-through and our beloved pf(4) can't > pf(4) can do this. I have a diff with me but if I send it in the present state, then Theo will catch my neck. :) I should be able to submit a diff soon. I need to modify it to meet the high standards of OpenBSD... Please hang on. Appreciate your patience. Thanks. regards, Girish
Re: mutiple pptp pass-through PF
lars, thanks for the reply. as for the pptp implementation, I just wanted to make PF do this (pass-through) like what other packet filtering (iptables, even PIX) can do. I know how unsafe this implementation is, but the site where we are currently getting this pptp connection to, is an old branch office and i don't manage their network. they are moving to the new facility where i have my pf firewalls in place, they need this pptp pass-through during transition as soon as everybody is moved here we can easily let this pptp go. on the other side of things it would be nice to make PF do this pptp pass through, it makes pf more of a over-all packet filter that can basically do "anything" and personally .. it may sound like a joke here but .. with all of pf's features .. i kinda envy crappy routers like LINKSYS that can do PPTP pass-through and our beloved pf(4) can't -b On Nov 20, 2007 12:51 AM, Lars Noodin <[EMAIL PROTECTED]> wrote: > Beavis wrote: > > ... I'm trying to run multiple pptp > > connections behind my 2 PF/carp firewalls. ... > > You should not be using PPTP. You have your choice, IPsec with > encryption or SSL with encryption: > http://www.vpnc.org/vpn-standards.html > > Allowing PPTP inside your LAN is to encourage use of insecure methods > and technologies that *cannot* be secured. > > You've got to move to IPsec sometime, why not now? > > If you are dealing with Apple, it may be helpful to reference earlier > bug reports regarding that serious security flaw. I myself filed > problem ID #5517198, but that is marked as a duplicate of #4316417. > > We'll see if they can be assed to fix the gaping holes in the system. > > Regards, > -Lars
Re: mutiple pptp pass-through PF
Beavis wrote: > ... I'm trying to run multiple pptp > connections behind my 2 PF/carp firewalls. ... You should not be using PPTP. You have your choice, IPsec with encryption or SSL with encryption: http://www.vpnc.org/vpn-standards.html Allowing PPTP inside your LAN is to encourage use of insecure methods and technologies that *cannot* be secured. You've got to move to IPsec sometime, why not now? If you are dealing with Apple, it may be helpful to reference earlier bug reports regarding that serious security flaw. I myself filed problem ID #5517198, but that is marked as a duplicate of #4316417. We'll see if they can be assed to fix the gaping holes in the system. Regards, -Lars
Re: mutiple pptp pass-through PF
hi!
On Mon, Nov 19, 2007 at 11:24:59AM -0600, Beavis wrote:
> hi folks,
>
> any pf folks available? I'm trying to run multiple pptp
> connections behind my 2 PF/carp firewalls. i was only successful to
> pass just 1 client and the rest gets denied for some weird reason. my
> pf.conf is below
>
>
> nat on $exT_if inet from any to any -> $ext_if
>
> block in all
> block out all
>
> pass in quick on $int_if inet proto { tcp, udp } from any to any port 1723
> pass in inet proto gre from any to any
> pass out inet proto gre from any to any
>
> am I missing some other config to let the rest go out?
>
>
> any comments would be awesomely appreciated.
>
pptp does not work with NAT, you need a proxy application to assist pf
in handling multiple pptp sessions.
the only existing pptp proxy that i know about is the "frickin pptp
proxy" (http://frickin.sourceforge.net/) but you shouldn't use this
proxy. you have been warned.
reyk
mutiple pptp pass-through PF
hi folks,
any pf folks available? I'm trying to run multiple pptp
connections behind my 2 PF/carp firewalls. i was only successful to
pass just 1 client and the rest gets denied for some weird reason. my
pf.conf is below
nat on $exT_if inet from any to any -> $ext_if
block in all
block out all
pass in quick on $int_if inet proto { tcp, udp } from any to any port 1723
pass in inet proto gre from any to any
pass out inet proto gre from any to any
am I missing some other config to let the rest go out?
any comments would be awesomely appreciated.
thanks,
-b
