[Firewall] Help: setting up port-forwarding

Arno van Amersfoort arnova at rocky.eld.leidenuniv.nl
Thu Nov 15 04:01:30 MST 2007


This is not available in my script. You could extract it from ifconfig 
but in principle you don't need it as the rp_filter already takes care 
of the antispoofing of IP's (including your external IP).... And most 
people first start their firewall before they bring their interface up....

a.

Philip Prindeville wrote:
> I sent more data out-of-band.
> 
> What the symbol would refer to would be "the address assigned to 
> $EXT_IF" in your scripts.
> 
> I.e. if you don't know what the address will be, because it's assigned 
> dynamically, then it would give you a way to specify it symbolically.
> 
> -Philip
> 
> 
> Arno van Amersfoort wrote:
>> I just tried it here. But I can't reproduce your problem. Setting the 
>> forward as 2201>192.168.1.1:22 without OPEN_TCP="22" just works. Note 
>> that the private site always accepts connections on port 22 (unless 
>> specifically denied), as the default policy for internal connections is 
>> accept.
>>
>> Maybe you could give some more details on your setup with ie. ip 
>> addresses etc. ?
>>
>> ps. I don't really understand what your special symbol/keyword note 
>> means, maybe you could clarify this?
>>
>>
>> a.
>>
>>
>> Philip Prindeville wrote:
>>   
>>> Let me know if you need copies of my configs, traces, or output from 
>>> "iptables --list".
>>>
>>> BTW:  It would be nice to have a special symbol or keyword mean "the 
>>> address of my
>>> external interface" (or interface #x) in the case of dynamic address 
>>> assignment...
>>>
>>> That way, one could explicitly specify it in rules (such as don't accept 
>>> packets coming to
>>> me with my own IP address as the source, etc).
>>>
>>> -Philip
>>>
>>>
>>> Arno van Amersfoort wrote:
>>>     
>>>> Setting NAT_TCP_FORWARD="2201>192.168.1.1:22" and leaving port 22 out of 
>>>> OPEN_TCP, *should* work. As I already said, you never need to open 
>>>> additional ports for port forwards, as these packets are processed in 
>>>> the PREROUTING chain. I'm currently having vacation but as soon as I get 
>>>> back at the university (next monday) I will try your configuration. 
>>>> Maybe, just maybe, a bug is creeping around somewhere....
>>>>
>>>> You don't see any (strange) packet drop or other messages in your 
>>>> firewall/kernel log?
>>>>
>>>> a.
>>>>
>>>> Philip Prindeville wrote:
>>>>   
>>>>       
>>>>> Well, I'm still not getting it.  If I have:
>>>>>
>>>>> NAT_TCP_FORWARD="2201>192.168.1.1:22"
>>>>>
>>>>> and 192.168.1.1 is my local (internal) address, then how do I accept 
>>>>> connections on my public side on 2201, but not on my public side on 22?  
>>>>> (And of course, accept connections on my private side on 22...)
>>>>>
>>>>> Or isn't that something I can do?
>>>>>
>>>>> Do I need to run to instances of "sshd" instead, and have each one 
>>>>> specifically bind to an interface and port?
>>>>>
>>>>> I was hoping to avoid that.
>>>>>
>>>>> -Philip
>>>>>     
>>>>>         
>>> _______________________________________________
>>> Firewall mailing list
>>> Firewall at lists.btito.net
>>> http://lists.btito.net/mailman/listinfo/firewall_lists.btito.net
>>> Arno's (Linux IPTABLES Firewall) Homepage:
>>> http://rocky.eld.leidenuniv.nl
>>>
>>>     
>>   
> 
> 
> _______________________________________________
> Firewall mailing list
> Firewall at lists.btito.net
> http://lists.btito.net/mailman/listinfo/firewall_lists.btito.net
> Arno's (Linux IPTABLES Firewall) Homepage:
> http://rocky.eld.leidenuniv.nl
> 

-- 
Arno van Amersfoort
E-mail    : arnova at rocky.eld.leidenuniv.nl
Donations are welcome through Paypal!
---------------------------------------------------------------------------
Arno's (Linux IPTABLES Firewall) Homepage:
http://rocky.eld.leidenuniv.nl



More information about the Firewall mailing list