<html style="direction: ltr;">
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
text="#000000">
<br>
<blockquote type="cite">After we've dealt with not touching traffic
we shouldn't by the NAT engine, now we're talking about something
else: <br>
recognizing GRE traffic - and understanding where it SHOULD go,<br>
based on the characteristics of the GRE packets themselves... <br>
my next question is going to be: does your kernel config have the
option NF_NAT_PROTO_GRE enabled?</blockquote>
No,the NF_NAT_PROTO_GRE.ko was in the kernel object library but
did not show up in lsmod. I added it to rc.local.<br>
It is loading now and showing up when " lsmod |grep _nat" is run
. I don't have access to remote servers for the time being,<br>
so I can't quite test the inbound & outbound connections for
PPTP . I may need to assemble a stub-LAN/WAN using KVM VM's.<br>
I assume that there is more to it then just loading the
NF_NAT_PROTO_GRE.ko, is there ?<br>
<br>
<br>
Guy<br>
<br>
<br>
<br>
<br>
On 11/18/2011 05:07 AM, shimi wrote:
<blockquote
cite="mid:CAKnt4U-La5r6Lo4pEzx7Hz+VPZ6g9KnuyD6kQsG3ay_e=8oD=w@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">On Fri, Nov 18, 2011 at 1:45 PM, Guy
Tetruashvyly <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:guy.tet@gmail.com">guy.tet@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="direction:ltr" bgcolor="#FFFFFF" text="#000000">
<div class="im">
<p> </p>
<blockquote type="cite">I understand from the NAT rule
that you expect the traffic to come FROM eth0 - i.e.
this is the interface connected to "INTERNET" (how? do
you have an additional home/NAT router there?) - as
otherwise it wouldn't do any NAT work for traffic
coming form the WAN (as it didn't come from
eth0)... <br>
</blockquote>
</div>
I did try $WAN_IP_Address$ instead of " -i eth0" on
that Dell-2900 , and what happened then was - the ACK
packets coming from an outside PPTP servers as response<br>
to SYN's - would be redirected to the LAN PPTP server
as per the router acting " OK, your a GRE packet, I got a
line for you in IPtables, you go there ", -<br>
,rather then to the host that initiated the
connection. ( Sorry for the cheap humanization of the
router, this is how I make TCP/IP order in my brain) .
<div class="im"><br>
</div>
</div>
</blockquote>
<div><br>
OK first, you don't have to do that _instead_, you could be
very good at doing -i eth0 -d $WAN_IP_Address$ - and quite
frankly, I would do that regardless of your problem. (from
my POV, rules should be as strict as possible to allow only
what's needed, and not a bit further...)<br>
<br>
After we've dealt with not touching traffic we shouldn't by
the NAT engine, now we're talking about something else:
recognizing GRE traffic - and understanding where it SHOULD
go, based on the characteristics of the GRE packets
themselves... my next question is going to be: does your
kernel config have the option NF_NAT_PROTO_GRE enabled?<br>
<br>
HTH,<br>
<br>
-- Shimi<br>
</div>
</div>
<br>
</div>
</blockquote>
</body>
</html>