Firewall Builder

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
>

Hahahahaha sorry i have to laught - the common trap
what you certainly forgot is to add your reversed objects -
Remeber those we added to your reverse translation nat rule

im not shore if you have to add in in source or destination (i always mix together myself)

but right now you only alow pakets on DESTINATION port 22 but we also have now SOURCE port 22 too
sames goes for 24 of course do not forget to add 24

best you try a new allow rule - 
object A1 - port 22 destination
object A2 - port 22 source
object B1 - port 24 destination
object B2 - port 24 source

put those 4 in source and target, also allow directions both and youll see it will work
of course you can reduce later to the real minimum required

you ll need to allow both "X2" objects as a source from internal on interface internal direction IN
and both "X1" rules viseversa for OUT

but maybe ive mixed it up in my head just try and error youll see (i hate reversed stuff :)



----- Ursprüngliche Mail -----
> Von: "Whit Blauvelt" <whit@...>
> An: fwbuilder-discussion@...
> Gesendet: Montag, 21. Mai 2012 17:40:41
> Betreff: [Fwbuilder-discussion] Two steps forward,	one step back - why is this blocked?
> 
> 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
>

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
> 
>

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
>

Hmm. Here's something I hadn't noticed. On the DNAT'd port 22-to-24 incoming
traffic sshd doesn't log anything immediately, but on control-C aborting the
request from the remote client it logs:

May 21 15:09:18 xy sshd[16960]: debug3: fd 7 is not O_NONBLOCK
May 21 15:09:18 xy sshd[16960]: debug1: Forked child 17603.
May 21 15:09:18 xy sshd[16960]: debug3: send_rexec_state: entering fd = 10 config len 329
May 21 15:09:18 xy sshd[16960]: debug3: ssh_msg_send: type 0
May 21 15:09:18 xy sshd[16960]: debug3: send_rexec_state: done
May 21 15:09:18 xy sshd[17603]: debug3: oom_adjust_restore
May 21 15:09:18 xy sshd[17603]: Set /proc/self/oom_score_adj to -1000
May 21 15:09:18 xy sshd[17603]: debug1: rexec start in 7 out 7 newsock 7 pipe 9 sock 10
May 21 15:09:18 xy sshd[17603]: debug1: inetd sockets after dupping: 3, 3
May 21 15:09:18 xy sshd[17603]: Connection from 77.88.99.70 port 39797
May 21 15:09:18 xy sshd[17603]: Did not receive identification string from 77.88.99.70

However with all iptables rules specifying "logging on", there's nothing
being logged on the firewall for the ACCEPTed packets, and no packets being
logged as DENY corresponding to 77.88.99.70. Which is weird. The ACCEPTed
packets don't get logged for the working port 22 connection either. This is
iptables 1.4.8 on Debian Sarge for the firewall box, and iptables 1.4.10
on the SSH VM on Ubuntu 11.10 with openssh-6.0p1 compiled from source.
Iptables is logging _some_ stuff, but not all of it.

Whit

On Mon, May 21, 2012 at 08:35:05PM +0200, bofh wrote:
> 
> 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

fishing in grey waters :)

i guess its getting logged but only the first few packes and oyu may missed em,
thing is fwbuilder usually sets the rules to stateful - so once a connection is establsihed youll get no loggings anymore at all
difference to stateless where every paket is inspected all the time

alsomaybe another rule aplys first

also it loosk like there is kinda connection incomming but not outgoing so the traffic back never reaches the ssh client
so the client can transmit the abort but never recieves an answer - so also no login or anything else

guess the dog is barried in the backtranslation

anyway its hard to say without debug it myself


i would now turn on login for every dam rule you can find and tail -f grep the ips hopefully you aint get much traffic on those machines 
or you may double filter  it in addition with source and dest ip




----- Ursprüngliche Mail -----
> Von: "Whit Blauvelt" <whit@...>
> An: "bofh" <bofh@...>
> CC: fwbuilder-discussion@...
> Gesendet: Montag, 21. Mai 2012 21:30:48
> Betreff: Re: [Fwbuilder-discussion] Two steps forward, one step back - why is this blocked?
> 
> Hmm. Here's something I hadn't noticed. On the DNAT'd port 22-to-24
> incoming
> traffic sshd doesn't log anything immediately, but on control-C
> aborting the
> request from the remote client it logs:
> 
> May 21 15:09:18 xy sshd[16960]: debug3: fd 7 is not O_NONBLOCK
> May 21 15:09:18 xy sshd[16960]: debug1: Forked child 17603.
> May 21 15:09:18 xy sshd[16960]: debug3: send_rexec_state: entering fd
> = 10 config len 329
> May 21 15:09:18 xy sshd[16960]: debug3: ssh_msg_send: type 0
> May 21 15:09:18 xy sshd[16960]: debug3: send_rexec_state: done
> May 21 15:09:18 xy sshd[17603]: debug3: oom_adjust_restore
> May 21 15:09:18 xy sshd[17603]: Set /proc/self/oom_score_adj to -1000
> May 21 15:09:18 xy sshd[17603]: debug1: rexec start in 7 out 7
> newsock 7 pipe 9 sock 10
> May 21 15:09:18 xy sshd[17603]: debug1: inetd sockets after dupping:
> 3, 3
> May 21 15:09:18 xy sshd[17603]: Connection from 77.88.99.70 port
> 39797
> May 21 15:09:18 xy sshd[17603]: Did not receive identification string
> from 77.88.99.70
> 
> However with all iptables rules specifying "logging on", there's
> nothing
> being logged on the firewall for the ACCEPTed packets, and no packets
> being
> logged as DENY corresponding to 77.88.99.70. Which is weird. The
> ACCEPTed
> packets don't get logged for the working port 22 connection either.
> This is
> iptables 1.4.8 on Debian Sarge for the firewall box, and iptables
> 1.4.10
> on the SSH VM on Ubuntu 11.10 with openssh-6.0p1 compiled from
> source.
> Iptables is logging _some_ stuff, but not all of it.
> 
> Whit
> 
> On Mon, May 21, 2012 at 08:35:05PM +0200, bofh wrote:
> > 
> > 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
>

On Mon, May 21, 2012 at 09:45:54PM +0200, bofh wrote:
> fishing in grey waters :)

Indeed.

> i guess its getting logged but only the first few packes and oyu may
> missed em, thing is fwbuilder usually sets the rules to stateful - so once
> a connection is establsihed youll get no loggings anymore at all
> difference to stateless where every paket is inspected all the time

Ah the stateful thing. That explains the silence. For years I've mostly
logged the denied packets (not using fwbuilder mostly), and ignored the good
stuff that gets through.

> also it loosk like there is kinda connection incomming but not outgoing so
> the traffic back never reaches the ssh client so the client can transmit
> the abort but never recieves an answer - so also no login or anything else

Actually, the abort gets through. The client's first packet gets through.
But then the client's key isn't received - at least we're told by sshd it
hasn't been yet when we send it the abort.

> i would now turn on login for every dam rule you can find and tail -f grep
> the ips hopefully you aint get much traffic on those machines or you may
> double filter it in addition with source and dest ip

The logging _is_ on for every rule (although stateful - hmm and set to
continue existing connections on firewall restart so those get inherited).
Looking at mere packet counts with iptraf in the sshd server the initial
packet's coming in and nothing's trying to go back out at all. So my guess
is sshd is just sitting there waiting, and waiting, and the key (or other
authentication request) is failing to follow the initial packet in. The
control-C though does make it in. 

Probably should turn on total logging in the ssh client to see where that's
at.

Or maybe I need to look at whether the "double NAT" concept in the Fwbuilder
manual can be applied usefully for this setup?

Whit

On 05/21/12 18:14, Whit Blauvelt wrote:

> 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?

What I suspect is that tcp is not establishing the connection because the
return packets are not routing correctly.  That will be before sshd gets involved.

Dick

true the backrouting could be an real issue

but it should still work, its way not unusual that your pakets comes back another way then they did get there, usual routing peering - so as long you reach both interfaces you should be good

however it wont be a failsafe solution unless you have a dual wan routing or setup static routes 
http://chris.olstrom.com/howto/setup-dual-wan/
one of many solutions for routing


anyway he need to investigate the logs first and narrow it down

also for testing setting up a static route to the test client would determine if this is the issue - but again if he can reach both interfaces form the outside it doenst matter at this stage ATM


still i dont see much benefit of the hole solution, an automatic loadbalancing /failover might be suited better and even easier to achieve 

----- Ursprüngliche Mail -----
> Von: "Dick Middleton" <dick@...>
> An: "Fwbuilder List (E-mail)" <fwbuilder-discussion@...>
> Gesendet: Montag, 21. Mai 2012 22:54:04
> Betreff: Re: [Fwbuilder-discussion] Two steps forward, one step back - why is this blocked?
> 
> On 05/21/12 18:14, Whit Blauvelt wrote:
> 
> > 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?
> 
> What I suspect is that tcp is not establishing the connection because
> the
> return packets are not routing correctly.  That will be before sshd
> gets involved.
> 
> Dick
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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
>

Dick was right. And for sanity's sake I've gone to two IPs on the internal
VM, as bofh suggested earlier, and gotten rid of the port translation. So
now if it comes in from one external IP, it DNAT's to one VM IP, and if the
other, then the other VM IP. The routing back out depends on rules for those
IPs pointing to tables with the routes for their interfaces as defaults.
Those tables already existed, so it was just a matter of adding a couple of
rules in the form:

ip ru add from 192.168.1.253 table isp1 prio 198
ip ru add from 192.168.1.254 table isp2 prio 199

And then it defaults out the way it came in. I don't believe SSH will allow
split routing, nor should it, so line consistency is required.

As I mentioned earlier this isn't about having outward failover - which I've
had for years in this setup. (Static routes and a bash script from cron - a
one-minute outage we can put up with.) This is about handling customers who
are trying to connect inward, in this case to sftp.ourcompany.com. When one
line goes down, our dynamic DNS (situated elsewhere) changes to point to the
second line. But it takes time for DNS to propogate, even with a small TTL
specified. So whichever line we're advertising through DNS, we need to still
provide service on the other line if we can at all, because the customer's
local DNS may not have caught up. In failback in particular if we do this
there's no gap in service.

There may still be a way to do this trick by port differentiaton rather than
by IP. The original docs on iproute2 mention a possiblity of policy routing
by port - where what I have now working is by IP. But I can't find any
documentation on whether this feature was actually implemented in iproute2,
or if so how to invoke it.

The intersection of iptables and iproute2 is opaque at best.

Thanks again for the generous help and advice.

Whit


On Tue, May 22, 2012 at 02:31:57AM +0200, bofh wrote:
> true the backrouting could be an real issue
> 
> but it should still work, its way not unusual that your pakets comes back another way then they did get there, usual routing peering - so as long you reach both interfaces you should be good
> 
> however it wont be a failsafe solution unless you have a dual wan routing or setup static routes 
> http://chris.olstrom.com/howto/setup-dual-wan/
> one of many solutions for routing
> 
> 
> anyway he need to investigate the logs first and narrow it down
> 
> also for testing setting up a static route to the test client would determine if this is the issue - but again if he can reach both interfaces form the outside it doenst matter at this stage ATM
> 
> 
> still i dont see much benefit of the hole solution, an automatic loadbalancing /failover might be suited better and even easier to achieve 
> 
> ----- Ursprüngliche Mail -----
> > Von: "Dick Middleton" <dick@...>
> > An: "Fwbuilder List (E-mail)" <fwbuilder-discussion@...>
> > Gesendet: Montag, 21. Mai 2012 22:54:04
> > Betreff: Re: [Fwbuilder-discussion] Two steps forward, one step back - why is this blocked?
> > 
> > On 05/21/12 18:14, Whit Blauvelt wrote:
> > 
> > > 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?
> > 
> > What I suspect is that tcp is not establishing the connection because
> > the
> > return packets are not routing correctly.  That will be before sshd
> > gets involved.
> > 
> > Dick
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > 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