[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: iptables question



Joe wrote:

> On Sat, 12 Nov 2016 22:15:45 +0100
> deloptes <deloptes@gmail.com> wrote:
> 
>> Hi,
>> I need some help and I'll appreciate it.
>> 
>> I have a firewall with iptables behind the modem.
>> on this firewall I have
>>         eth0 with ip 10..1 to the modem ip: 10..12
>>         eth1 with ip 192..1 to the intranet
>> 
>> iptables is doing SNAT from 192..1 to 10..1
>> 
>> I wonder how I can ssh from 192..NN to 10..NN
>> What magic should I apply to make it happen?
>> 
>> Thanks in advance
>> 
>> 
> 
> Can we take it that this does not work now? If that is the case, are
> you sure that iptables is preventing it? There are other possible
> reasons for a new ssh link not to work.
> 

Yes, it is not working and yes it might be a different issue. So here is
some additional information, if you wish.

>From one computer ip 10..6 I can ssh to 10..7 and vv.
I also see that iptables forwards to the output, but in the output nothing
happens. So it is either in the output chain, or the back route blocks.

> A typical simple iptables script will allow what you want to do to
> happen already, so there must either be some iptables restriction in
> place now, or there is some other reason for ssh not working. Are you
> able to connect to the modem web configuration page from the 192.
> network?
> 

Yes I forgot to mention that I can connect from 192..NN to the modem ip via
ssh lets say 10..200.

On the modem there is also firewall. I tried disableing it but it did not
help.

And you can bet there is restriction - basically it is pretty tight and is
opened only what is needed to intranet and basically all to modem net

> The SNAT should not be an issue, it can handle all protocols
> transparently, and ssh uses the same tcp protocol as http.
> 
> If there are iptables restrictions on outgoing protocols, you need to
> find the rule permitting tcp/80 to be forwarded, copy it and replace 80
> with 22. Once this is working, we can restrict the destination to the
> 10. network, as presumably any existing port 80 rule allows connection
> to anywhere and you may not want that for ssh.

there is nothing regarding the output - no rules based on ports

thanks


Reply to: