Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #174611 > unrolled thread

iptables question

Back to article view | Back to linux.debian.user

Contents

  iptables question deloptes <deloptes@gmail.com> - 2016-11-12 22:20 +0100
    Re: iptables question Joe <joe@jretrading.com> - 2016-11-12 23:40 +0100
      Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 01:30 +0100
        Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 10:50 +0100
        Re: iptables question Michael Milliman <michael.e.milliman@gmail.com> - 2016-11-13 12:40 +0100
          Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 16:10 +0100
            Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 18:00 +0100
              Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 20:50 +0100
                Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 21:20 +0100
                  Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-13 21:50 +0100
                    Re: iptables question Henning <henning@itcfollmann.com> - 2016-11-13 22:50 +0100
                      Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 23:30 +0100
                        Re: iptables question Henning <henning@itcfollmann.com> - 2016-11-14 00:30 +0100
                          Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 00:50 +0100
                            Re: iptables question Henning Follmann <hfollmann@itcfollmann.com> - 2016-11-14 13:10 +0100
                              Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 20:20 +0100
                    Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 23:30 +0100
                      Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 01:00 +0100
                        Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-14 23:10 +0100
        Re: iptables question Igor Cicimov <icicimov@gmail.com> - 2016-11-14 03:10 +0100
          Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 08:20 +0100
            Re: iptables question deloptes <deloptes@gmail.com> - 2016-11-14 09:10 +0100
      Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 10:40 +0100
        Re: iptables question Joe <joe@jretrading.com> - 2016-11-13 11:10 +0100
          Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 11:40 +0100
            Re: iptables question Joe <joe@jretrading.com> - 2016-11-13 13:40 +0100
              Re: iptables question Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-13 15:00 +0100
                Re: iptables question Igor Cicimov <icicimov@gmail.com> - 2016-11-14 03:00 +0100

Page 1 of 2  [1] 2  Next page →

#174611 — iptables question

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

[toc] | [next] | [standalone]

#174613

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.

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?

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.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#174619

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

[toc] | [prev] | [next] | [standalone]

#174630

Le 13/11/2016 à 01:19, deloptes a écrit :
>
> Yes, it is not working

How is it not working ? What do you do and what happens ?

> From one computer ip 10..6 I can ssh to 10..7 and vv.

That does not concern the firewall between the modem and the LAN.

> I also see that iptables forwards to the output, but in the output nothing
> happens.

This does not make any sense. Iptables does not forward anything. It 
just accepts, drops or mangles packets.

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

Huh ? What are these addresses ? The source, the destination ?

It would be much simple if you provided the output of iptables-save so 
we can see your ruleset.

[toc] | [prev] | [next] | [standalone]

#174637

[Multipart message — attachments visible in raw view] — view raw

On 11/12/2016 06:19 PM, deloptes wrote:
> 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.
Ok, this confuses me a little.  I thought the modem was 10..12? 
Nevertheless, it sounds like you have the ability to connect to 
_something_ on the 10. network.  Therefore, I would suspect the settings 
on the 10. machine that you are not able to communicate with.  Also, the 
192. machine could be blocking (on the input chain) all communications 
from 10. except from the specific ip address of the modem.  One of the 
other respondents indicated that posting a (sanitized) copy of your 
ruleset would help, this is indeed the case.
> On the modem there is also firewall. I tried disableing it but it did not
> help.
The firewall on the modem should not affect the communications between 
192. and 10. from what I understand of your setup.  You have a firewall 
machine with two NICs one on the 192. network and one on the 10. 
network.  The modem is on the 10. network along with some other machines 
(presumably with a switch or router) and the firewall is acting as a 
bridge between the 192. and the 10.
>
> 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
Again, posting the exact ruleset would be helpful.

[toc] | [prev] | [next] | [standalone]

#174655

[Multipart message — attachments visible in raw view] — view raw

Michael Milliman wrote:

> Again, posting the exact ruleset would be helpful.

These are the rules - a friend created this like 10y ago. I added few rules
to forward ports from outside to the intranet and to be able to handle VPN.
You can ignore  192.168.60.1 on eth2 - not used.

Another important information perhaps is that the modem is configured to
have a DMZ with 10.0.0.1.

Devices 10.0.0.6 and 10.0.0.7 which I want to connect from 192.... do not
have any firewalls - they are mobile phones.

I will really appreciate your help - perhaps reviewing the rules and
suggesting improvements as well.

thank you in advance

regards

[toc] | [prev] | [next] | [standalone]

#174659

Le 13/11/2016 à 16:05, deloptes a écrit :
>
> These are the rules - a friend created this like 10y ago. I added few rules
> to forward ports from outside to the intranet and to be able to handle VPN.
> You can ignore  192.168.60.1 on eth2 - not used.

IMO, this ruleset is totally insane.

However, after clearing out all irrelevant rules, I see nothing in what 
is left which may block connections from 192.168.40.0/24 on eth1 to 
anywhere through the firewall :

*nat
:PREROUTING ACCEPT [26000:2533530]
:POSTROUTING ACCEPT [87:4966]
:OUTPUT ACCEPT [28:2038]
-A POSTROUTING -s 192.168.40.0/24 -o eth0 -j SNAT --to-source 10.0.0.1
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:ifilter - [0:0]
:ofilter - [0:0]
-A INPUT -j ifilter
-A FORWARD -j ifilter
-A FORWARD -j ofilter
-A OUTPUT -j ofilter
-A ifilter -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ifilter -i eth1 -m state --state NEW -j ACCEPT

What happens exactly when your try to connect ? What is the command, 
what is the reply ? Did you make a packet capture on eth0 ?

Did you check the routing table on the firewall and the targets ? Do 
they have a route to all the 10.0.0.0/24 range ?

> Another important information perhaps is that the modem is configured to
> have a DMZ with 10.0.0.1.

I don't think this is relevant. The modem is not involved.

> Devices 10.0.0.6 and 10.0.0.7 which I want to connect from 192.... do not
> have any firewalls - they are mobile phones.
>
> I will really appreciate your help - perhaps reviewing the rules and
> suggesting improvements as well.

This ruleset does not need improvements but a total rewrite.

[toc] | [prev] | [next] | [standalone]

#174663

Pascal Hambourg wrote:

> Le 13/11/2016 à 16:05, deloptes a écrit :
>>
>> These are the rules - a friend created this like 10y ago. I added few
>> rules to forward ports from outside to the intranet and to be able to
>> handle VPN.
>> You can ignore  192.168.60.1 on eth2 - not used.
> 
> IMO, this ruleset is totally insane.
> 

Haha, yes for me it is also hard to understand it all ... but as I said in
the past 10y it did a good work.

> However, after clearing out all irrelevant rules, I see nothing in what
> is left which may block connections from 192.168.40.0/24 on eth1 to
> anywhere through the firewall :
> 
> *nat
> :PREROUTING ACCEPT [26000:2533530]
> :POSTROUTING ACCEPT [87:4966]
> :OUTPUT ACCEPT [28:2038]
> -A POSTROUTING -s 192.168.40.0/24 -o eth0 -j SNAT --to-source 10.0.0.1
> COMMIT
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
> :ifilter - [0:0]
> :ofilter - [0:0]
> -A INPUT -j ifilter
> -A FORWARD -j ifilter
> -A FORWARD -j ofilter
> -A OUTPUT -j ofilter
> -A ifilter -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A ifilter -i eth1 -m state --state NEW -j ACCEPT
> 
> What happens exactly when your try to connect ? What is the command,
> what is the reply ? Did you make a packet capture on eth0 ?
> 

I do ssh user@10...6 and nothing happens - connection time out after ~1min

> Did you check the routing table on the firewall and the targets ? Do
> they have a route to all the 10.0.0.0/24 range ?
> 

the one I posted is on the firewall - firewall is the one I am trying to
modify.
I am not sure that I have a rule to all the 10.0.0.0/24 range, but even if I
replace 10.0.0.1/32 with 10.0.0.0/24 it does not work

>> Another important information perhaps is that the modem is configured to
>> have a DMZ with 10.0.0.1.
> 
> I don't think this is relevant. The modem is not involved.
> 

The modem is a wireless modem so the cable goes to the firewall 10..1 and
via the wlan I have 10..6 etc. So IMO it is involved, but I do not have
root on it - I have only the admin iface and there I see firewall is active
and setup in normal mode (you have easy and hard - translated from the
local language)

>> Devices 10.0.0.6 and 10.0.0.7 which I want to connect from 192.... do not
>> have any firewalls - they are mobile phones.
>>
>> I will really appreciate your help - perhaps reviewing the rules and
>> suggesting improvements as well.
> 
> This ruleset does not need improvements but a total rewrite.

Yes I was thinking the same, I'll put it on the TODO. I even tried once with
fw builder - it couldn't even import properly, because import and export
produced not working firewall.
IT is a bit complicated. However I think the ruleset is not that bad as
testing from outside shows the network 192.168... is well protected

thanks

regards

[toc] | [prev] | [next] | [standalone]

#174665

Le 13/11/2016 à 20:40, deloptes a écrit :
> Pascal Hambourg wrote:
>
>> Did you check the routing table on the firewall and the targets ? Do
>> they have a route to all the 10.0.0.0/24 range ?
>
> the one I posted is on the firewall - firewall is the one I am trying to
> modify.

The one you posted ? I didn't see a routing table in any of your posts.

> I am not sure that I have a rule to all the 10.0.0.0/24 range, but even if I
> replace 10.0.0.1/32 with 10.0.0.0/24 it does not work

You should double check that.

>> This ruleset does not need improvements but a total rewrite.
>
> Yes I was thinking the same, I'll put it on the TODO. I even tried once with
> fw builder - it couldn't even import properly, because import and export
> produced not working firewall.

Just insert this rule and check whether it changes anything :

iptables -I FORWARD -j ACCEPT

If SSH works then the ruleset is faulty and I'll have to double-check 
it. If SSH does not work, then the cause is elsewhere.

You can remove the rule with

iptables -D FORWARD -j ACCEPT

[toc] | [prev] | [next] | [standalone]

#174667

Pascal Hambourg wrote:

>> replace 10.0.0.1/32 with 10.0.0.0/24 it does not work
> 
> You should double check that.
> 

I checked replaced 10.0.0.1/32 with 10.0.0.0/24.

>>> This ruleset does not need improvements but a total rewrite.
>>
>> Yes I was thinking the same, I'll put it on the TODO. I even tried once
>> with fw builder - it couldn't even import properly, because import and
>> export produced not working firewall.
> 
> Just insert this rule and check whether it changes anything :
> 
> iptables -I FORWARD -j ACCEPT
> 
> If SSH works then the ruleset is faulty and I'll have to double-check
> it. If SSH does not work, then the cause is elsewhere.
> 
> You can remove the rule with
> 
> iptables -D FORWARD -j ACCEPT

it does not work

regards

[toc] | [prev] | [next] | [standalone]

#174672

I followed this thread and i wonder if there is a sane reason why you do nat inside your network. Why don't you just route between different subnets i.e.  10.0.1.0/24 and 10.0.2.0/24
you still can have a firewall between those subnets

-H

[toc] | [prev] | [next] | [standalone]

#174674

Le 13/11/2016 à 22:27, Henning a écrit :
> I followed this thread and i wonder if there is a sane reason why you do nat inside your network. Why don't you just route between different subnets i.e.  10.0.1.0/24 and 10.0.2.0/24

Probably because the modem and hosts in 10.0.0.0/24 don't know about 
192.168.40.0/24.

[toc] | [prev] | [next] | [standalone]

#174676

> On Nov 13, 2016, at 5:19 PM, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> 
>> Le 13/11/2016 à 22:27, Henning a écrit :
>> I followed this thread and i wonder if there is a sane reason why you do nat inside your network. Why don't you just route between different subnets i.e.  10.0.1.0/24 and 10.0.2.0/24
> 
> Probably because the modem and hosts in 10.0.0.0/24 don't know about 192.168.40.0/24.
> 

And usually there is no reason for two separate rfc1918 address ranges.
Pick one matching your address space needs and design subnets.
There is only one single reason for nat: you have more hosts than routable ip addresses. I guess 10.0.0.0 meets even the biggest organizations.

-H

[toc] | [prev] | [next] | [standalone]

#174677

Henning wrote:

> And usually there is no reason for two separate rfc1918 address ranges.
> Pick one matching your address space needs and design subnets.
> There is only one single reason for nat: you have more hosts than routable
> ip addresses. I guess 10.0.0.0 meets even the biggest organizations.

Thank you for the line of argumentation. As usual if something works for 10y
it undergoes a lot of changes. So the reason for not using 10.0.0.0
internally is that it is historically that way. Some years ago the firewall
was connected to the public network directly. The new provider gave me the
modem and it uses automatically 10.0.0.0, which I can not influence. I just
did the DMZ - this was the time I tried to rewrite the firewall rules, but
I found out I need to read again a lot about iptables and more important it
would mean I would need to experiment and jeopardize the network.
The setup is useful in the way that the whole wireless network is outside
the firewall in the 10.0.0.0/24 range. All that I need for operating works
perfectly. Now the only problem is that I can not access anything else on
the 10.0.0.0 network except the modem.

thanks again

[toc] | [prev] | [next] | [standalone]

#174690

On Mon, Nov 14, 2016 at 12:45:20AM +0100, deloptes wrote:
> Henning wrote:
> 
> > And usually there is no reason for two separate rfc1918 address ranges.
> > Pick one matching your address space needs and design subnets.
> > There is only one single reason for nat: you have more hosts than routable
> > ip addresses. I guess 10.0.0.0 meets even the biggest organizations.
> 
> Thank you for the line of argumentation. As usual if something works for 10y
> it undergoes a lot of changes. So the reason for not using 10.0.0.0
> internally is that it is historically that way. Some years ago the firewall
> was connected to the public network directly. The new provider gave me the
> modem and it uses automatically 10.0.0.0, which I can not influence. I just
> did the DMZ - this was the time I tried to rewrite the firewall rules, but
> I found out I need to read again a lot about iptables and more important it
> would mean I would need to experiment and jeopardize the network.
> The setup is useful in the way that the whole wireless network is outside
> the firewall in the 10.0.0.0/24 range. All that I need for operating works
> perfectly. Now the only problem is that I can not access anything else on
> the 10.0.0.0 network except the modem.
> 
> thanks again
> 
> 

Last time I chime in here.
I understand growth and chaos, believe me. However sometimes we need a
nudge or a kick in the but to clean up. Maybe this is your call.
Simplicity is a beautiful thing my friend.


-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

[toc] | [prev] | [next] | [standalone]

#174709

Henning Follmann wrote:

> Last time I chime in here.
> I understand growth and chaos, believe me. However sometimes we need a
> nudge or a kick in the but to clean up. Maybe this is your call..

It is kicking me and calling me since some time but I can not do this before
next summer. I have to sit there with RS232 cable to be able to do the
testing and repair if something fails. Perhaps I have luck and I can do it
earlier, but not very likely.

> Simplicity is a beautiful thing my friend

yes indeed - as I mentioned I did not write this and I don'T know why the
guy who wrote it, did it that way.

regards

[toc] | [prev] | [next] | [standalone]

#174673

Le 13/11/2016 à 21:43, deloptes a écrit :
> Pascal Hambourg wrote:
>
>>> replace 10.0.0.1/32 with 10.0.0.0/24 it does not work
>>
>> You should double check that.
>
> I checked replaced 10.0.0.1/32 with 10.0.0.0/24.
>
>> Just insert this rule and check whether it changes anything :
>>
>> iptables -I FORWARD -j ACCEPT
>>
>> If SSH works then the ruleset is faulty and I'll have to double-check
>> it. If SSH does not work, then the cause is elsewhere.
>>
>> You can remove the rule with
>>
>> iptables -D FORWARD -j ACCEPT
>
> it does not work

Well then, all I can suggest is to run a packet capture and try to see 
what's going on.

[toc] | [prev] | [next] | [standalone]

#174678

Pascal Hambourg wrote:

> Well then, all I can suggest is to run a packet capture and try to see
> what's going on.

I guess  you mean on the firewall? I am not even sure I can install tcpdump
there, but I will try and ask again for help here for sure

thanks

[toc] | [prev] | [next] | [standalone]

#174720

Le 14/11/2016 à 00:48, deloptes a écrit :
> Pascal Hambourg wrote:
>
>> Well then, all I can suggest is to run a packet capture and try to see
>> what's going on.
>
> I guess  you mean on the firewall?

Yes.

[toc] | [prev] | [next] | [standalone]

#174683

[Multipart message — attachments visible in raw view] — view raw

On 13 Nov 2016 11:20 am, "deloptes" <deloptes@gmail.com> wrote:
>
> 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
>

Run tcpdump and check whats happening

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web