ahm simple method to trace the error - please do the following
set all rules where you allow your ssh on the gateway tp loggin on
best during test use tail -f |grep ....
so you can see in realtime whats going on
on the destination host do the same, do not deaktivate iptables, let it run its ok - just active the logging for ssh rules
- you maybe want to make a single rule for ssh only so you log only that traffic
next 2 ssh windows for both servers and monitor it realtime with tail
now try to connect from OUTSIDE
WARNING IMPORTANT - do not test it from any internal machine or the gateway itself - this could cause trouble
test it really by an outside line - like a 3gphone or so
----- Ursprüngliche Mail -----
> Von: "Whit Blauvelt" <whit@...>
> An: "Chris Martin" <chris@...>
> CC: fwbuilder-discussion@...
> Gesendet: Montag, 21. Mai 2012 19:14:14
> Betreff: Re: [Fwbuilder-discussion] Two steps forward, one step back - why is this blocked?
>
> Hi Chris,
>
> That's another step forward. Now it goes to:
>
> RULE 15 -- DENY IN=br3 OUT=br0 PHYSIN=eth3 ... SRC=77.88.99.70
> DST=192.168.1.254 ... PROTO=TCP SPT=39100 DPT=24
>
> So I add a rule for 192.168.1.254:24, and it gets through to the
> internal
> system where I know sshd is waiting on port 24 as well as 22:
>
> May 21 12:32:55 xxyy sshd[16751]: Received SIGHUP; restarting.
> May 21 12:32:55 xxyy sshd[16894]: Server listening on 0.0.0.0 port
> 24.
> May 21 12:32:55 xxyy sshd[16894]: Server listening on :: port 24.
> May 21 12:32:55 xxyy sshd[16894]: Server listening on 0.0.0.0 port
> 22.
> May 21 12:32:55 xxyy sshd[16894]: Server listening on :: port 22.
>
> (I can log also into ssh on port 24 from the firewall.)
>
> I know the outside connection attempt comes through the firewall
> system to
> the IP tables instance on the ssh server:
>
> May 21 12:33:07 xxyy kernel: [7586100.598393] RULE 2 -- ACCEPT
> IN=eth0 OUT= ... SRC=77.88.99.70 DST=192.168.1.254 ... PROTO=TCP
> SPT=39170 DPT=24 ...
>
> yet SSH does nothing - nothing in auth.log. Setting sshd's LogLevel
> to
> DEBUG3 doesn't show anything either:
>
> May 21 12:44:48 xxyy sshd[16894]: Received SIGHUP; restarting.
> May 21 12:44:48 xxyy sshd[16960]: debug3: oom_adjust_setup
> May 21 12:44:48 xxyy sshd[16960]: Set /proc/self/oom_score_adj from
> -1000 to -1000
> May 21 12:44:48 xxyy sshd[16960]: debug2: fd 3 setting O_NONBLOCK
> May 21 12:44:48 xxyy sshd[16960]: debug1: Bind to port 24 on 0.0.0.0.
> May 21 12:44:48 xxyy sshd[16960]: Server listening on 0.0.0.0 port
> 24.
> May 21 12:44:48 xxyy sshd[16960]: debug2: fd 4 setting O_NONBLOCK
> May 21 12:44:48 xxyy sshd[16960]: debug3: sock_set_v6only: set socket
> 4 IPV6_V6ONLY
> May 21 12:44:48 xxyy sshd[16960]: debug1: Bind to port 24 on ::.
> May 21 12:44:48 xxyy sshd[16960]: Server listening on :: port 24.
> May 21 12:44:48 xxyy sshd[16960]: debug2: fd 5 setting O_NONBLOCK
> May 21 12:44:48 xxyy sshd[16960]: debug1: Bind to port 22 on 0.0.0.0.
> May 21 12:44:48 xxyy sshd[16960]: Server listening on 0.0.0.0 port
> 22.
> May 21 12:44:48 xxyy sshd[16960]: debug2: fd 6 setting O_NONBLOCK
> May 21 12:44:48 xxyy sshd[16960]: debug3: sock_set_v6only: set socket
> 6 IPV6_V6ONLY
> May 21 12:44:48 xxyy sshd[16960]: debug1: Bind to port 22 on ::.
> May 21 12:44:48 xxyy sshd[16960]: Server listening on :: port 22.
>
> So iptables on the WAN-LAN firewall now DNATs to port 24, sends the
> request
> through where iptables on the SSH box ACCEPTs it ... and sshd, known
> to be
> listening on port 24, doesn't even acknowledge it sees the attempt
> when set
> to its highest debug level....
>
> Dropping the iptables firewall entirely from the SSH server doesn't
> change
> things. I can confirm with iptraf that the initial packet gets there
> on port
> 24, but sshd continues to ignore it. On the other hand, logging in
> remotely
> through the other public IP which stays on port 22 works instantly,
> and gets
> logged in detail by sshd.
>
> So what can the DNAT port translation be doing to the packets that
> would
> cause sshd to just totally ignore them, rather than at least
> registering a
> complaint?
>
> Whit
>
>
>
>
>
> On Tue, May 22, 2012 at 02:08:55AM +1000, Chris Martin wrote:
> > You need to add port 24 to your iptables Forwarding rules.
> >
> > Cheers
> > ----------------------------------------------------------
> > Chris Martin
> > m: +61 419 812 371
> > e: chris@...
> > ----------------------------------------------------------
> >
> >
> >
> >
> > On 22 May 2012 01:40, Whit Blauvelt <whit@...> wrote:
> >
> > Hi,
> >
> > This is in the context of NAT'ing SSH to an internal system,
> > which I've
> > discussed here recently - which got me forward in the project,
> > for which
> > again thanks!
> >
> > Where I'm stuck now is someplace that should be far simpler,
> > and makes me
> > scratch my head harder. On the firewall I've got DNAT rules
> > that end up as
> > rules 4 & 5 and look like:
> >
> > $IPTABLES -t nat -A PREROUTING -p tcp -m tcp -d 11.22.33.120
> > --dport 22
> > -j DNAT --to-destination 192.168.1.254 --persistent
> > $IPTABLES -t nat -A PREROUTING -p tcp -m tcp -d 44.55.66.120
> > --dport 22
> > -j DNAT --to-destination 192.168.1.254:24 --persistent
> >
> > And for good measure a rule later on, rule 10, that compiles
> > to:
> >
> > $IPTABLES -A OUTPUT -p tcp -m tcp -d 11.22.33.120 --dport 22
> > -m state
> > --state NEW -j ACCEPT
> > $IPTABLES -A OUTPUT -p tcp -m tcp -d 44.55.66.120 --dport 22
> > -m state
> > --state NEW -j ACCEPT
> > $IPTABLES -A FORWARD -p tcp -m tcp -d 11.22.33.120 --dport
> > 22 -m state
> > --state NEW -j ACCEPT
> > $IPTABLES -A INPUT -p tcp -m tcp -d 11.22.33.120 --dport 22
> > -m state
> > --state NEW -j ACCEPT
> > $IPTABLES -A FORWARD -p tcp -m tcp -d 44.55.66.120 --dport
> > 22 -m state
> > --state NEW -j ACCEPT
> > $IPTABLES -A INPUT -p tcp -m tcp -d 44.55.66.120 --dport 22
> > -m state
> > --state NEW -j ACCEPT
> >
> > Where 11.22.33.120 is the IP to be DNAT'd on the first outside
> > line, and
> > 44.55.66.120 is the IP on the second line. (Do I even need all
> > that with
> > the
> > DNAT in PREROUTING?)
> >
> > There are also some SNAT rules to get stuff back out correctly,
> > but the
> > current glitch is before those.
> >
> > I can ping both IPs remotely. I can connect through to the
> > internal SSH
> > server via the 11.22.33.120 IP from outside. But when I go to
> > connect to
> > the
> > internal SSH server via 44.55.66.120 iptables blocks it:
> >
> > RULE 15 -- DENY IN=br3 OUT= PHYSIN=eth3 ... SRC=77.88.99.70
> > DST=
> > 44.55.66.120 ... PROTO=TCP SPT=38597 DPT=22 ...
> >
> > How is this possible? How can traffic arriving as TCP for port
> > 22 on
> > 44.55.66.120 drop through first the DNAT rule 5, then the
> > "allow all port
> > 22
> > TCP traffic to 44.55.66.120" lines in rule 10, to hit DENY from
> > the
> > catchall
> > final rule 15?
> >
> > Whit
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security
> > and
> > threat landscape has changed and how IT managers can respond.
> > Discussions
> > will include endpoint security, mobile security and the latest
> > in malware
> > threats.
> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Fwbuilder-discussion mailing list
> > Fwbuilder-discussion@...
> > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion
> >
> >
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.
> Discussions
> will include endpoint security, mobile security and the latest in
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Fwbuilder-discussion mailing list
> Fwbuilder-discussion@...
> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion
>
|