Very Computer

by **will** » Mon, 29 Jul 2002 02:50:57

Hi,

Running Debian/testing with iptables 1.2.6a-6

I downloaded the patch from http://www.roeder.goe.net/~koepi/
downloaded the clean 2.4.18 source from kernel.org
put the patch in the source root dir for 2.4.18
ran: patch -p1 -E *patchname*
It patched fine.
Then did a:
make dep clean bzImage modules modules_install
installed the kernel and added to Lilo.
Kernel boots fine, but when i check all the network modules i get a
'unresolved symbols in ip_nat_pptp.o'
Am i doing something wrong or is this patch not suitable for 2.4.18?

many thanks
Willem

by **Pietr** » Tue, 30 Jul 2002 16:47:18

> Kernel boots fine, but when i check all the network modules i get a
> 'unresolved symbols in ip_nat_pptp.o'

I had the same problem, but seams that pptp is not important/required
for ip_conntrack_h323. However, I was not able setup the iptables rule
for the h323 maquerding...
Does nobody have any succesful experinece with that ?

p
--

by **Cedric Blanche** » Tue, 30 Jul 2002 18:58:13

>> Kernel boots fine, but when i check all the network modules i get a
>> 'unresolved symbols in ip_nat_pptp.o'
> I had the same problem, but seams that pptp is not important/required
> for ip_conntrack_h323. However, I was not able setup the iptables rule
> for the h323 maquerding...
> Does nobody have any succesful experinece with that ?

Well ip_nat_pptp is only useful if your export PPTP tunnels from
multiple clients behinf NAT to the same peer.

I had something work for fun using classical IP masquerade stuff, for it
has been generalized to handle all IP stuff, including GRE. That is not
true for 2.2.x kernels.

But, if two different clients open a tunnel with the same server, there
can be conflicts, so the use of ip_nat_pptp which is designed to track
control channel and solve this kind of problem.

You can also masquerade a server, using port redirection :

iptables -t nat -A PREROUTING -p 47 -j DNAT --to myserver
iptables -t nat -A PREROUTING -p tcp --dport 1723 \
-j DNAT --to myserver

--
BOFH excuse #362:

Plasma conduit breach

by **Rich Piotrowsk** » Wed, 31 Jul 2002 06:35:39

>> Kernel boots fine, but when i check all the network modules i get a
>> 'unresolved symbols in ip_nat_pptp.o'

>I had the same problem, but seams that pptp is not important/required
>for ip_conntrack_h323. However, I was not able setup the iptables rule
>for the h323 maquerding...
>Does nobody have any succesful experinece with that ?

>p

Yes, I have. You only need apply the "newnat" and "h323" patches from
patch-o-matic. Recompile and then load the following modules;

/sbin/insmod ip_nat_h323
/sbin/insmod ip_conntrack_h323

The only "iptables" configuration needed is to open TCP Ports
1503,1720 and 1731. Also all udp ports >1024.

It works just fine here. The only caveat is that the machine behind
the firewall must initiate the call.

If you are trying to get NetMeeting to work, an even better method can
be found here;

http://openh323proxy.sourceforge.net/

This is great because anyone connected to the Gatekeeper can then call
any *one* other user connected to the Gatekeeper. It is definitely
more work initially. The openh323 libraries wouldn't even compile on
my machine untill I bumped the memory to 256M. The upside is once it
is done and working, you are not eternally screwing around with
patching the kernel sources every time you update your kernel.
Rich Piotrowski

Very Computer

2.4.18-5 and newnat patch(H323)

2.4.18-5 and newnat patch(H323)

2.4.18-5 and newnat patch(H323)

2.4.18-5 and newnat patch(H323)

2.4.18-5 and newnat patch(H323)