<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">
<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)...</blockquote>
</p>
You make a good point,I'll explain : ( I was just about to say "
OK, you found the problem, but then I remembered ... )<br>
eth0 has eth0:1 "on it" , eth0 is the WAN interface, eth0:1 is
the LAN. Yes, it jumps right into mind "hey, well as far as<br>
IPtables is concerned, they are the same interface" . Because
it's been 4 months that I'm trying to solve this, I can't recall<br>
every step that I took 1:1, but, I know that the same issue
occurred when working on an old Dell-2900 server that had a physical
NICs pointing to WAN/LAN.<br>
Once we've enabled RRAS on a Windows server and pointed the
PPTP/GRE to it, we had intermittent success with PPTP'ing out from
our PC's. <br>
I do recall using "-i eth0" and -d $WAN_IP_Address$ as the
splitting argument when having 2 phyiscal NIC's with the same
unwelcome results. <br>
<br>
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) .<br>
<br>
<blockquote type="cite">This is an obvious one, but I'll ask
anyways: Any chance you have OTHER rules that may have caused
this?</blockquote>
No, in the T-shooting process I cleared every single rule that
may get in the way.<br>
Even in full function, the rules are simple and no "crossfire"
is anticipated, one PPTP LAN server and one SIP server .<br>
<br>
<br>
<br>
Guy<br>
<br>
<br>
<br>
<br>
<br>
On 11/18/2011 04:09 AM, shimi wrote:
<blockquote
cite="mid:CAKnt4U9LNcdcYxiwygHve+nZUfX1N7vQvsKYUBKeMR=VTDxsng@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<br>
<div class="gmail_quote">2011/11/18 Guy Tetruashvyly <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:guy.tet@gmail.com">guy.tet@gmail.com</a>></span><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">
Greetings,<br>
this is an issue I've been struggling with for months now,
didn't even make small headway . <br>
<br>
Scheme :<br>
LAN----Linux_X86_ROUTER----INTERNET , so far, very simple.<br>
<br>
I have a PPTP server that's on the LAN, and has a LAN IP
address (only) .<br>
The Router is forwarding GRE and TCP port 1723 to that
PPTP server, the router is using Netfilter/IPtables.<br>
<br>
The same issue, which I'll describe pretty soon, Happens
with a phone system ( Asterisk) , that's on the LAN, which
only has a LAN address, as well.<br>
And has UDP and TCP port 5060 forwarded to it , by the
same router.<br>
<br>
Here is the syntax that I used in order to forward the
ports, I'll only note one of the cases, the same applies
to all other DNAT cases :<br>
<br>
iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 1723
-j DNAT –to-destination 10.12.35.8 >> DNAT's
tcp:1723 to 10.12.35.8<br>
iptables -A FORWARD -p tcp -d 10.12.35.8 –dport 1723 -j
ACCEPT >> allows the forwarding action listed
above . <br>
<br>
the forwarding works great, and I have phones and other
PC's PPTP'ing and registering phones to my LAN from the
wild . <br>
<br>
BUT !!<br>
<br>
The problem is with my LAN hosts, that, once the
forwarding rules are applied, <br>
they are unable to use those services, if their
destination host is outside of my LAN.<br>
Example :if I'll PPTP VPN with one of my LAN host to an
outside address, it will actually VPN to my LAN PPTP
server.<br>
This is understandable, due to the fact that the router
will forward all traffic as it's commanded to,<br>
and it knows that all tcp:1723 and GRE go to host
10.12.35.8 ( same will be with SIP) .<br>
<br>
</div>
</blockquote>
<div><br>
There is some info missing, so I am going to take a guess
here, and please correct me if I'm wrong...<br>
<br>
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>
<br>
So my question is this: If this is indeed the case, I would
like you to first understand your following statement:<br>
<br>
"This is understandable, due to the fact that the router
will forward all traffic as it's commanded to,<br>
and it knows that all tcp:1723 and GRE go to host 10.12.35.8
( same will be with SIP) ."<br>
<br>
...which you said about traffic, that as far as I
understand, came FROM THE LAN, or in other words, _NOT_ FROM
ETH0 - why would then an iptables rule with -i eth0 apply to
such traffic? This is NOT understandable whatsoever (if I
got all the facts you described right) - and needs an
explanation.<br>
<br>
This is an obvious one, but I'll ask anyways: Any chance you
have OTHER rules that may have caused this?<br>
<br>
HTH,<br>
<br>
-- Shimi<br>
</div>
</div>
<br>
</div>
</blockquote>
</body>
</html>