Re: Iptables PREROUTING Not All Working

Hello,

Noboby a écrit :
>
> $IPTABLES -A FORWARD -i xxx.xx.xx.51 -o $INTIF -m state --state
> ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -i $INTIF -o xxx.xx.xx.51 -j ACCEPT

-o/-i take an interface name, not an address (nor an alias such as
eth1:1). Source/destination address matching is done with -s/-d.

Noboby a écrit :
> Pascal Hambourg wrote:
>>
>> -o/-i take an interface name, not an address (nor an alias such as
>> eth1:1). Source/destination address matching is done with -s/-d.
>
> Can I or should I use the virtual external address with -o

What was not clear in "-o/-i take an interface name, not an address" ?

> or just use -s with the virtual external address?

I don't know. Probably not. What do you want to achieve ? Please post
the complete relevant rules.

Noboby a écrit :
>
> echo " Dropping outbound smtp from inside."
>
> # Assume MTA on the gateway box, nothing from the LAN needs to contact
> # the world on port 25 directly.
>
> # Log packets trying to cross the interfaces.
> $IPTABLES -A FORWARD -p tcp --dport 25 -j LOG
>
> # Drop those packets
> $IPTABLES -A FORWARD -p tcp --dport 25 -j DROP
>
> echo " Enabling SNAT (MASQUERADE) functionality on $EXTIF"
> $IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
> #$IPTABLES -t nat -A POSTROUTING -s xxx.xx.xx.50 -j MASQUERADE
>
> echo " Enabling Terminal Services redirection."
>
> $IPTABLES -t nat -A PREROUTING -p tcp --dport 3389 --dst xxx.xx.xx.49
> -j DNAT --to-destination 10.1.1.98
>
> echo " Enabling phone vpn redirection."
> $IPTABLES -t nat -A PREROUTING -p tcp --dport 3389 --dst xxxx.xx.xx.50
> -j DNAT --to-destination 10.1.1.112

What kind of VPN uses TCP port 3389 ?

> $IPTABLES -t nat -A POSTROUTING -s 10.0.1.112 -j SNAT --to-destination
> 173.11.168.50

SNAT has no --to-destination option. What is the purpose of this rule ?
Shouldn't it be 10.1.1.112 instead of 10.0.1.112 ?

Is this the complete ruleset ?

> .50 is on eth1:1 and is pingable without the PREROUTING rule.

The PREROUTING rule matches only TCP, I don't see how it could make ping
(ICMP echo) fail.

> Would prefer all ports for this
> particular application. .112 is a test machine on the inside and I
> would like ALL traffice to .50 to be redirected to .112 .

Just remove "-p tcp --dport 3389" from the DNAT rule.

PS : This is not going anywhere. You just say "it does not work" but you
don't say *what* does not work and *how* it does not work, e.g. you
don't provide any packet trace. How do you expect any help ?

Noboby a écrit :
> Pascal Hambourg wrote:
>> Noboby a écrit :
>
>>> echo " Enabling phone vpn redirection."
>>> $IPTABLES -t nat -A PREROUTING -p tcp --dport 3389 --dst xxxx.xx.xx.50
>>> -j DNAT --to-destination 10.1.1.112
>> What kind of VPN uses TCP port 3389 ?
>
> Since I could not reach the router on the inside,

What router on the inside ?

> I tried reaching a
> Windows machine. 3389, as you may know, is the port for Remote Desktop
> on a Windows machine.

Ok.

>>> $IPTABLES -t nat -A POSTROUTING -s 10.0.1.112 -j SNAT --to-destination
>>> 173.11.168.50
>>
>> SNAT has no --to-destination option. What is the purpose of this rule ?
>> Shouldn't it be 10.1.1.112 instead of 10.0.1.112 ?
>
> I read that a POSTROUTING rule was necessary.

Not for a redirection (DNAT). It affects only outgoing connections, not
incoming connections.

> Yes, typo, should be 10.1.1.112,

And --to-destination should be --to-source.

>> The PREROUTING rule matches only TCP, I don't see how it could make ping
>> (ICMP echo) fail.
>
> Good point, but it does. Perhaps in combination with another rule.

No, it doesn't. A rule with "-p tcp" cannot affect ICMP packets.

> Sorry, I thought it would be obvious from my statements. As an example,
> for the test 3389 port I should be able to connect to the Windows
> machine at .112 with Remote Desktop from the outside using the .50 . I
> cannot. Even after correcting the typo, I cannot.

Connect to the Windows box with RDP involves more than the DNAT rule :
- the DNATed packets in states NEW,ESTABLISHED must be accepted in the
FORWARD chain
- the Windows box firewall must accept the packets
- the Windows box must run the RDP service
- the Windows box must have a route back to the source through the Linux
box (default gateway)
- the return packets from the Windows box in state ESTABLISHED must be
accepted in the FORWARD chain

I suggest you use packet capture on each interface of the Linux and the
Windows boxes on the path to check whether the packets are transmitted
as expected. You can also insert LOG rules to log these packets through
the iptables chains.