PPTPD connection tracking
in [Linux Networking]
|
Prev: interface rename ?
Next: ipsec rouing problem
From: Pascal Hambourg on 26 Nov 2006 19:49 Clifford Kite a �crit : > > I meant this option under "Core Netfilter Configuration:" > > <M> Netfilter Xtables support (required for ip_tables) Ok. But AFAIK, Xtables has nothing to do with conntrack & NAT helpers. > This, under "IP: Netfilter Configuration," must be what you mean: > > x <M> Connection tracking (required for masq/NAT) x > x CONFIG_IP_NF_CONNTRACK: x No, this is the legacy IPv4 connection tracking inherited from kernel 2.4. I meant this : Layer 3 Independent Connection tracking CONFIG_NF_CONNTRACK: Connection tracking keeps a record of what packets have passed through your machine, in order to figure out how they are related into connections. Layer 3 independent connection tracking is experimental scheme which generalize ip_conntrack to support other layer 3 protocols. which is available in "Core Netfilter Configuration" only when you deselect CONFIG_IP_NF_CONNTRACK because they are incompatible with each other.
From: Clifford Kite on 27 Nov 2006 10:51 Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> wrote: > Clifford Kite a �crit : >> This, under "IP: Netfilter Configuration," must be what you mean: >> >> x <M> Connection tracking (required for masq/NAT) x >> x CONFIG_IP_NF_CONNTRACK: x > No, this is the legacy IPv4 connection tracking inherited from kernel > 2.4. I meant this : > Layer 3 Independent Connection tracking > CONFIG_NF_CONNTRACK: > Connection tracking keeps a record of what packets have passed > through your machine, in order to figure out how they are related > into connections. > Layer 3 independent connection tracking is experimental scheme > which generalize ip_conntrack to support other layer 3 protocols. > which is available in "Core Netfilter Configuration" only when you > deselect CONFIG_IP_NF_CONNTRACK because they are incompatible with each > other. I think we may be using different kernels - it's 2.6.18 here. There's nothing to indicate it is a legacy IPv4 item, notice it says "required for masq/NAT." But there _is_ something resembling what you describe in the last three lines above. It's rather annoying too, because when you select/deselect < > Netfilter netlink interface in the section "Core Netfilter Configuration," the configuration item < > Connection tracking netlink interface (EXPERIMENTAL) (NEW) [from the help: CONFIG_IP_NF_CONNTRACK_NETLINK] in the section "IP: Netfilter Configuration" appears/disappears! Grrr.. No wonder the split into two sections gave me a headache when configuring the kernel. -- Clifford Kite /* I hear and I forget. I see and I remember. I do and I understand. --Confucius, 551-479 BC */
From: markvr on 28 Nov 2006 10:26 Pascal Hambourg wrote: > Hello, > > markvr a écrit : > > Clifford Kite wrote: > > > >>markvr <markvanrossum(a)gmail.com> wrote: > >> > >>>I am having problems with pptp VPNs from XP clients, through a NATting > >>>Linux box with redhat compiled kernel 2.6.9 going to PoPToP linux > >>>boxes. > > Where is the NAT box located ? On the client or server side ? And what > does it do exactly ? Does it SNAT/MASQUERADE communications from the > clients to the outside or DNAT communications from the outside to the > servers ? Do the clients share the same public IP address ? XP(internal range) -> ProblemLinuxBoxWithNating (public & private IP)->Internet->LinuxHostWithPopTop(public IP) > > >>>Both VPNs with and without MPPE crypto aren't working. > > I don't think MPPE is an issue here. What do you mean exactly by "aren't > working" ? I shall clarify: No VPNs with MPPE work at all. The logs on the remote POPTOP server show errors about GRE tunnel failing. The VPNs without MPPE work sometimes, but not reliably. They may connect once, and then try again later and they won't connect. Windows gives errors about "the connection could not be established". > > >>>These were > >>>working fine with an old linux box with kernel 2.4.something so I am > >>>confused as to why it has stopped working now we have upgraded the > >>>firewall to a later release of RedHat. > > Maybe the kernel 2.4 included the pptp-contrack-nat patch from the > patch-o-matic(-ng) but the kernel 2.6.9 was not. I don't know what the old kernel included, it was the standard "RedHat/CentOS" one for v3. > > >>>The firewall has TCP port 1723 and GRE being allowed through at both > >>>ends. > > Both ends ? Yes. Nothing here changed except the NATting box was upgraded, the firewall script was copied over. > > >>>I've tried to re-compile the latest kernel 2.6.18 making sure to > >>>include pptpd_connection tracking but it still doesn't seem to be > >>>working. > > What do you mean exactly by "doesn't seem to be working" ? If the PPTP > conntrack and NAT helper was compiled as modules, did you load the > modules ip_conntrack_pptp.ko and ip_nat_pptp.ko ? See above. Yep, tried loading them. No luck. Other things NAT fine, just not PPTP connections. I'm getting out of my depth here. I've never tried to compile a kernel before and all these code forks and different types of conntracking is getting a bit beyond me! I was hoping there would be a simple solution. At the moment the old box is back in and working, but has hardware issues. I think I'll just put CentOS 3 onto new hardware as that seems to work. Thanks for the replies. mark
From: Pascal Hambourg on 30 Nov 2006 11:08 Clifford Kite a �crit : > > I think we may be using different kernels - it's 2.6.18 here. Same here. > There's > nothing to indicate it is a legacy IPv4 item, notice it says "required > for masq/NAT." "Legacy" does not mean it is obsolete yet (actually I didn't mean it). The new layer 3 independent nf_conntrack still lacks some important functionnalities such as IPv4 NAT, so the old ip_conntrack is still required for NAT. > But there _is_ something resembling what you describe > in the last three lines above. Above what ?
From: Clifford Kite on 30 Nov 2006 11:39
Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> wrote: > "Legacy" does not mean it is obsolete yet (actually I didn't mean it). > The new layer 3 independent nf_conntrack still lacks some important > functionnalities such as IPv4 NAT, so the old ip_conntrack is still > required for NAT. >> But there _is_ something resembling what you describe >> in the last three lines above. > Above what ? Above the current line. -- Clifford Kite /* My confidence in this answer (X), on a scale of 0 to 10: |----|----|----|----|----|----|----|----|----|----X 0----1----2----3----4----5----6----7----8----9----10 */ |