<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Nov 18, 2011 at 1:45 PM, Guy Tetruashvyly <span dir="ltr"><<a 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>