|
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)...
You make a good point,I'll explain : ( I was just about to say "
OK, you found the problem, but then I remembered ... )
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
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
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.
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.
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.
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
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 ", -
,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) .
This is an obvious one, but I'll ask
anyways: Any chance you have OTHER rules that may have caused
this?
No, in the T-shooting process I cleared every single rule that
may get in the way.
Even in full function, the rules are simple and no "crossfire"
is anticipated, one PPTP LAN server and one SIP server .
Guy
On 11/18/2011 04:09 AM, shimi wrote:
2011/11/18 Guy Tetruashvyly <[email protected]>
Greetings,
this is an issue I've been struggling with for months now,
didn't even make small headway .
Scheme :
LAN----Linux_X86_ROUTER----INTERNET , so far, very simple.
I have a PPTP server that's on the LAN, and has a LAN IP
address (only) .
The Router is forwarding GRE and TCP port 1723 to that
PPTP server, the router is using Netfilter/IPtables.
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.
And has UDP and TCP port 5060 forwarded to it , by the
same router.
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 :
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
iptables -A FORWARD -p tcp -d 10.12.35.8 –dport 1723 -j
ACCEPT >> allows the forwarding action listed
above .
the forwarding works great, and I have phones and other
PC's PPTP'ing and registering phones to my LAN from the
wild .
BUT !!
The problem is with my LAN hosts, that, once the
forwarding rules are applied,
they are unable to use those services, if their
destination host is outside of my LAN.
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.
This is understandable, due to the fact that the router
will forward all traffic as it's commanded to,
and it knows that all tcp:1723 and GRE go to host
10.12.35.8 ( same will be with SIP) .
There is some info missing, so I am going to take a guess
here, and please correct me if I'm wrong...
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)...
So my question is this: If this is indeed the case, I would
like you to first understand your following statement:
"This is understandable, due to the fact that the router
will forward all traffic as it's commanded to,
and it knows that all tcp:1723 and GRE go to host 10.12.35.8
( same will be with SIP) ."
...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.
This is an obvious one, but I'll ask anyways: Any chance you
have OTHER rules that may have caused this?
HTH,
-- Shimi
|
