Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #200358 > unrolled thread
| Started by | Subhadip Ghosh <subhadip.sky@gmail.com> |
|---|---|
| First post | 2018-09-21 05:10 +0200 |
| Last post | 2018-09-24 20:50 +0200 |
| Articles | 5 on this page of 85 — 22 participants |
Back to article view | Back to linux.debian.user
Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 05:10 +0200
Re: Why does Debian allow all incoming traffic by default Roberto C. Sánchez <roberto@debian.org> - 2018-09-21 05:30 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 05:40 +0200
Re: Why does Debian allow all incoming traffic by default Roberto C. Sánchez <roberto@debian.org> - 2018-09-21 05:50 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 07:10 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:40 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-21 19:10 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:40 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 20:00 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 20:10 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 21:40 +0200
Re: Why does Debian allow all incoming traffic by default David Wright <deblis@lionunicorn.co.uk> - 2018-09-21 21:50 +0200
Re: Why does Debian allow all incoming traffic by default mick crane <mick.crane@gmail.com> - 2018-09-23 01:10 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-23 20:00 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-23 23:00 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-24 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 09:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 11:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:00 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-22 13:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 17:00 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 20:20 +0200
Re: Why does Debian allow all incoming traffic by default Richard Hector <richard@walnut.gen.nz> - 2018-09-24 05:20 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 05:30 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-24 09:10 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 11:00 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-24 11:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-24 14:20 +0200
Re: Why does Debian allow all incoming traffic by default Dan Ritter <dsr@randomstring.org> - 2018-09-22 20:30 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 22:20 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-22 22:40 +0200
Re: Why does Debian allow all incoming traffic by default Gene Heskett <gheskett@shentel.net> - 2018-09-22 23:20 +0200
Re: Why does Debian allow all incoming traffic by default Simon Kengelbacher <simon.kengelbacher@mail.ch> - 2018-09-22 23:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-23 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Simon Kengelbacher <simon.kengelbacher@mail.ch> - 2018-09-23 00:20 +0200
SSH X forwarding going awry (Was: Why does Debian allow all incoming traffic by default) Étienne Mollier <etienne.mollier@mailoo.org> - 2018-09-23 11:40 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Gene Heskett <gheskett@shentel.net> - 2018-09-23 16:10 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Joe <joe@jretrading.com> - 2018-09-23 23:00 +0200
Re: SSH X forwarding going awry FIXED (Was: Why does Debian allow all incoming traffic by default) Gene Heskett <gheskett@shentel.net> - 2018-09-24 04:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 21:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-23 00:00 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 21:00 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-24 21:30 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-26 17:10 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 19:30 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 16:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-21 15:00 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 18:30 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 20:20 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 20:40 +0200
Re: Why does Debian allow all incoming traffic by default Brian <ad44@cityscape.co.uk> - 2018-09-21 21:10 +0200
Re: Why does Debian allow all incoming traffic by default deloptes <deloptes@gmail.com> - 2018-09-21 23:20 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-21 23:40 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 00:10 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 09:10 +0200
Re: Why does Debian allow all incoming traffic by default Dan Purgert <dan@djph.net> - 2018-09-22 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 09:50 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 12:00 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:00 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 13:30 +0200
Re: Why does Debian allow all incoming traffic by default <tomas@tuxteam.de> - 2018-09-22 22:00 +0200
Re: Why does Debian allow all incoming traffic by default Stefan Monnier <monnier@iro.umontreal.ca> - 2018-09-22 22:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 23:40 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-22 12:10 +0200
Re: Why does Debian allow all incoming traffic by default Reco <recoverym4n@gmail.com> - 2018-09-22 12:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 13:10 +0200
netstat (was: Re: Why does Debian allow all incoming traffic by default) rhkramer@gmail.com - 2018-09-21 20:00 +0200
Re: netstat Reco <recoverym4n@gmail.com> - 2018-09-21 20:20 +0200
Re: netstat rhkramer@gmail.com - 2018-09-22 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Re: Why does Debian allow all incoming traffic by default Henning Follmann <hfollmann@itcfollmann.com> - 2018-09-24 21:30 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-26 15:50 +0200
Re: Why does Debian allow all incoming traffic by default Pablo Álvarez Córdoba <pabloalvarezcordoba@protonmail.ch> - 2018-09-21 18:30 +0200
Re: Why does Debian allow all incoming traffic by default Subhadip Ghosh <subhadip.sky@gmail.com> - 2018-09-21 19:30 +0200
Re: Why does Debian allow all incoming traffic by default songbird <songbird@anthive.com> - 2018-09-22 00:10 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-22 09:40 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 10:40 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-22 13:20 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-22 17:10 +0200
Re: Why does Debian allow all incoming traffic by default Joe <joe@jretrading.com> - 2018-09-23 10:50 +0200
Re: Why does Debian allow all incoming traffic by default Pascal Hambourg <pascal@plouf.fr.eu.org> - 2018-09-27 14:00 +0200
Re: Why does Debian allow all incoming traffic by default Jonathan Dowland <jmtd@debian.org> - 2018-09-24 20:50 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2018-09-22 13:20 +0200 |
| Message-ID | <wAO77-3Sp-5@gated-at.bofh.it> |
| In reply to | #200419 |
On Sat, 22 Sep 2018 10:38:52 +0200 Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > Le 22/09/2018 à 09:39, Joe a écrit : > > > > Two layers of NAT work just fine, for anything but IPSec. > > 1) Even one single layer of NAT can cause trouble with other > applications that IPSec : FTP, SIP... > Yes, but one can reasonably expect NAT hardware to also deal with tracking of multiple port/protocol communications. Pretty much the same basic code does both jobs, as well as stateful firewalling. There's a reason that NAT is implemented by iptables rules. Only IPSec ties in the endpoint IP addresses as well. > 2) IPSec works through NAT, provided that you enable UDP > encapsulation aka NAT-T. > Yes, there's more to go wrong, though. IPSec is commonly used to provide pretty much fixed communication between organisations, so terminating it on the Internet interface rather than on an internal machine makes sense, as well as keeping it simple with just the public IP addresses. Other VPNs such as PPTP are more commonly used from internal workstations. PPTP will pass through two* layers of NAT at each end without special provision being made, apart from forwarding of course. *Presumably unlimited layers, but I've actually done two at each end. I don't like commenting on any communications method until I've made it work myself. I've had a certain amount of trouble with IPSec, though to be fair that was in the days when most router manufacturers were still getting the hang of connection tracking. There was plenty of early NAT router firmware which didn't even handle PPTP well. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-22 17:10 +0200 |
| Message-ID | <wARHH-61D-1@gated-at.bofh.it> |
| In reply to | #200429 |
Le 22/09/2018 à 13:11, Joe a écrit : > On Sat, 22 Sep 2018 10:38:52 +0200 > Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > >> Le 22/09/2018 à 09:39, Joe a écrit : >>> >>> Two layers of NAT work just fine, for anything but IPSec. >> >> 1) Even one single layer of NAT can cause trouble with other >> applications that IPSec : FTP, SIP... > > Yes, but one can reasonably expect NAT hardware to also deal with > tracking of multiple port/protocol communications. Pretty much the same > basic code does both jobs, as well as stateful firewalling. Each complex protocol requires specific handling by both NAT and connection tracking. You can always work around the lack of connection tracking support with static firewall rules (at the cost of weaker security), but you cannot always work around the lack of NAT support with static NAT rules. >> 2) IPSec works through NAT, provided that you enable UDP >> encapsulation aka NAT-T. >> > Yes, there's more to go wrong, though. Like what ? > IPSec is commonly used to > provide pretty much fixed communication between organisations, so > terminating it on the Internet interface rather than on an internal > machine makes sense, as well as keeping it simple with just the public > IP addresses. IPSec is also commonly used by organisations for remote access by travelling employees. > Other VPNs such as PPTP are more commonly used from > internal workstations. PPTP will pass through two* layers of NAT at > each end without special provision being made, apart from forwarding of > course. PPTP does require specific NAT support for the GRE protocol. Use case : two clients of the same PPTP server share the same public IP address. The server sends a GRE packet to the public IP address. How does the NAT device know which client the packet must be forwarded to ?
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2018-09-23 10:50 +0200 |
| Message-ID | <wB8fv-7bb-5@gated-at.bofh.it> |
| In reply to | #200440 |
On Sat, 22 Sep 2018 17:07:59 +0200 Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > PPTP does require specific NAT support for the GRE protocol. > Use case : two clients of the same PPTP server share the same public > IP address. It doesn't work, see below. And yes, I do know, it was a common question on the MS Small Business Server Usenet group. The second person to make the attempt could not make contact until about two minutes after the first had disconnected. > The server sends a GRE packet to the public IP address. How does the > NAT device know which client the packet must be forwarded to ? > Because NAT requires the maintenance of a table of connections, with source and destination IP addresses, which is exactly what is required by both stateful firewalling and connection tracking. In this case, for the first GRE packet, it is connection tracking which uses the table data to route the packet to the machine with an existing TCP/1723 connection from the same source address. What you can't do with PPTP is make multiple connections between the same two NAT machines, for this same reason, because GRE doesn't have the means for being tied to one particular TCP/1723 path. It doesn't carry the same meta information as does the TCP protocol. It is here that IPSec is used, almost always between the network default gateways, to avoid messy routing updates to workstations. FTP doesn't have this problem, because its two paths are both TCP, and can be uniquely paired by connection tracking. There is provision in the PPTP protocol for multiple GRE connections to be handled by one TCP/1723 control channel, but I'm not aware that this has ever been implemented. That would still be a server-to-server protocol, not a multiple-workstation-to-server one. -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2018-09-27 14:00 +0200 |
| Message-ID | <wCD7z-2Ua-3@gated-at.bofh.it> |
| In reply to | #200469 |
Le 23/09/2018 à 10:41, Joe a écrit : > On Sat, 22 Sep 2018 17:07:59 +0200 > Pascal Hambourg <pascal@plouf.fr.eu.org> wrote: > >> PPTP does require specific NAT support for the GRE protocol. >> Use case : two clients of the same PPTP server share the same public >> IP address. > > It doesn't work, see below. It can work if and only if the NAT device has specific support for PPTP. The GRE header used by PPTP contains a "Call ID" field which acts as a sort of destination port and can be used to associate the packet with an existing PPTP session. > The second > person to make the attempt could not make contact until about two > minutes after the first had disconnected. Yes, until the GRE mapping created for the previous session has expired. >> The server sends a GRE packet to the public IP address. How does the >> NAT device know which client the packet must be forwarded to ? > > Because NAT requires the maintenance of a table of connections, with > source and destination IP addresses, which is exactly what is required > by both stateful firewalling and connection tracking. In this case, for > the first GRE packet, it is connection tracking which uses the table > data to route the packet to the machine with an existing TCP/1723 > connection from the same source address. If the NAT layer has no specific support for PPTP, there is no relationship between the TCP control connection and the GRE streams. If the first GRE packet is sent by the PPTP server, it is just discarded by the NAT box because no mapping exists yet. The first GRE packet sent by a private client creates a NAT mapping which is used to forward subsequent packets sent by the server. > What you can't do with PPTP is make multiple connections between the > same two NAT machines, for this same reason, because GRE doesn't have > the means for being tied to one particular TCP/1723 path. It doesn't > carry the same meta information as does the TCP protocol. Actually it does, as I mentioned above. When establishing a session over the TCP control connection, the client and server exchange "Call ID" numbers which are present in the header of the GRE packets sent within that session. The Call ID field can be used by NAT as a destination port. AFAIK, Netfilter PPTP/GRE conntrack and NAT helper modules use it.
[toc] | [prev] | [next] | [standalone]
| From | Jonathan Dowland <jmtd@debian.org> |
|---|---|
| Date | 2018-09-24 20:50 +0200 |
| Message-ID | <wBE5H-IS-5@gated-at.bofh.it> |
| In reply to | #200406 |
On Fri, Sep 21, 2018 at 06:04:59PM -0400, songbird wrote: > whenever i install a new system i include ufw (a firewall >program) just to catch any funny stuff that might try to >come through. Another vote for ufw from me. It's certainly easier for the simple use-cases than raw iptables (and has some nicer properties), I think it's also significantly nicer than firewall-cmd, a similar tool that has a much worse UX for the simplest case. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.debian.user
csiph-web