[Firewall] redirecting a port from INET to a different port on router

Philip A. Prindeville philipp_subx at redfish-solutions.com
Mon Jan 19 20:03:59 CET 2009


I had a default gateway...

-Philip


Arno van Amersfoort wrote:
> I will try to test this myself ASAP. Note that you do need to have a 
> default gateway setup to make this work....
>
> a.
>
> Philip A. Prindeville wrote:
>> Just did a build... testing now...
>>
>> Didn't work:
>>
>> Jan 14 22:54:33 pbx user.info kernel: AIF:PRIV connect attempt: 
>> IN=ppp0 OUT= MAC= SRC=66.232.79.143 DST=192.168.10.1 LEN=60 TOS=0x00 
>> PREC=0x00 TTL=55 ID=61868 DF PROTO=TCP SPT=48197 DPT=22 WINDOW=5840 
>> RES=0x00 SYN URGP=0
>>
>> I tried forwarding it to:
>>
>> xxx>y.y.y.y~22
>>
>> where "xxx" is the relocated port, and "y.y.y.y" is my external IP 
>> address. Didn't work.
>>
>> Also tried:
>>
>> xxx>192.168.10.1~22
>>
>> which is one of my inside addresses, and that didn't work either.
>>
>> I suspect the connection state might not be set up correctly.
>>
>> -Philip
>>
>>
>> Arno van Amersfoort wrote:
>>> Just added some code that could potentially fix this, please grab 
>>> the latest nightly/devel script, test and report back.....
>>>
>>> a.
>>>
>>> Arno van Amersfoort wrote:
>>>> I think the problem is the route back, which is normally handled by 
>>>> NAT. I'll try to think about a clever solution for this....
>>>>
>>>> a.
>>>>
>>>> Philip A. Prindeville wrote:
>>>>> Arno van Amersfoort wrote:
>>>>>> AFAIK you don't need NAT enabled for the device to make this 
>>>>>> work. I once changed this to allow people to still forward ports 
>>>>>> even when NAT/masquerade was disabled. Only thing you need to 
>>>>>> make sure in this case is that your routing is setup properly.
>>>>>>
>>>>>> a.
>>>>>>
>>>>>> Darrick Hartman wrote:
>>>>>>> Roman Mamedov wrote:
>>>>>>>> On Tue, 30 Dec 2008 12:32:28 +0100
>>>>>>>> Arno van Amersfoort <arnova at rocky.eld.leidenuniv.nl> wrote:
>>>>>>>>
>>>>>>>>> I think you could simply abuse the NAT_FORWARD_xxx variables for
>>>>>>>>> this. Something like
>>>>>>>>> NAT_FORWARD_TCP="10101>{HOST_IP}:101"
>>>>>>>>> a.
>>>>>>>>
>>>>>>>> In fact, wouldn't 127.0.0.1 work here too?
>>>>>>>>
>>>>>>>>> NAT_FORWARD_TCP="10101>127.0.0.1:101"
>>>>>>>>
>>>>>>>> That way the redirect rule would not depend on host's INET 
>>>>>>>> (external)
>>>>>>>> IP to stay permanent.
>>>>>>>>
>>>>>>>
>>>>>>> Interesting. I tried to use: 
>>>>>>> NAT_FORWARD_TCP="10101>192.168.1.1:101" (where 192.168.1.1 is 
>>>>>>> the internal IP address of the device that Arno's IPtable 
>>>>>>> firewall is running on) but I don't think we're really NAT'ing 
>>>>>>> for the device we're running on so it did not work. I'll have to 
>>>>>>> try with 127.0.0.1, but I don't think it's going to work.
>>>>>
>>>>> I just tried it and it times out:
>>>>>
>>>>> Jan 1 16:49:17 pbx user.info kernel: Connection attempt (PRIV): 
>>>>> IN=br0 OUT= PHYSIN=eth0 
>>>>> MAC=00:00:24:c9:28:a4:00:01:64:d8:4c:1c:08:00 SRC=X.X.X.X 
>>>>> DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=64209 DF 
>>>>> PROTO=TCP SPT=43072 DPT=22 WINDOW=5840 RES=0x00 SYN
>>>>>
>>>>> Tried it also for 127.0.0.1 (both were with 1.8.8o, but this 
>>>>> hasn't changed significantly) and I get:
>>>>>
>>>>> Jan 1 16:52:09 pbx user.warn kernel: martian destination 127.0.0.1 
>>>>> from Y.Y.Y.Y, dev br0
>>>>>
>>>>> I think we need to have special handling for these packets... 
>>>>> maybe using marking, for instance.
>>>>>
>>>>>



More information about the Firewall mailing list