Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #5018 > unrolled thread
| Started by | Mike Mocha <mocha@mailexcite.com> |
|---|---|
| First post | 2022-02-09 08:16 +0000 |
| Last post | 2022-02-15 09:16 -0800 |
| Articles | 20 on this page of 174 — 14 participants |
Back to article view | Back to comp.os.linux.networking
IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-09 08:16 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 10:01 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:18 +0100
Re: IPv6 Hardware Firewall Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2022-02-09 15:17 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-09 16:39 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-09 11:16 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-09 16:54 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-09 17:57 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:27 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:59 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:14 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 20:39 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:25 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:45 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 22:24 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:49 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:48 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 11:01 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 19:15 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:44 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 21:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:01 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:49 +0100
Re: IPv6 Hardware Firewall Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-02-13 19:43 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 21:14 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:47 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:48 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:08 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:19 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:09 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 20:43 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:06 -0700
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-10 21:54 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-11 14:22 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 14:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:35 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 19:39 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:06 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:50 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:36 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 07:55 +0100
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 03:59 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:02 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-13 18:05 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:13 -0800
Re: IPv6 Hardware Firewall Bit Twister <BitTwister@mouse-potato.com> - 2022-02-15 11:36 -0600
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 20:32 -0800
Re: IPv6 Hardware Firewall "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2022-02-15 23:39 -0500
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:50 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:09 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:29 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:52 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-12 19:40 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-13 13:58 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:53 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:28 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:04 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:17 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 10:59 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 14:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 11:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 20:11 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:17 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 09:29 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:08 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:00 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-10 04:08 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 08:30 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 10:56 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-10 19:49 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 12:13 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 04:07 +0000
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-10 21:33 +0000
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-10 14:48 -0700
Re: IPv6 Hardware Firewall "Vincent Coen" <VBCoen@gmail.com> - 2022-02-11 01:20 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:35 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 11:45 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 20:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-11 12:14 -0700
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:33 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 09:27 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 11:01 +0100
OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-12 12:06 -0800
Re: OT Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-12 21:39 +0100
Re: OT Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 13:27 -0800
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:12 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:06 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:14 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-10 10:10 +0100
Re: IPv6 Hardware Firewall Mike Mocha <mocha@mailexcite.com> - 2022-02-11 07:28 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-11 09:41 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:38 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 11:49 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 13:51 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-13 14:54 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-13 15:31 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-13 14:07 -0800
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:25 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 12:15 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-15 21:18 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-15 18:18 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:24 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-16 13:16 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:20 -0700
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 01:53 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 09:37 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-16 19:50 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-17 11:41 +0000
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:22 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 16:26 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 16:48 +0000
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:13 +0100
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-16 19:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-16 20:56 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 21:18 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-17 11:06 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:27 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 08:26 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 12:05 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:41 -0700
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:43 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:20 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:34 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:46 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:03 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:39 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:52 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 14:05 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-20 22:50 +0000
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-20 18:10 -0800
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 08:16 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 08:57 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-21 18:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-21 11:31 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-21 21:09 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-22 16:44 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-20 08:51 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:11 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:41 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:13 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-20 07:42 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:33 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-18 20:47 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:03 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 10:35 -0700
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-18 20:36 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-18 13:41 -0700
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-19 07:43 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:08 +0100
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-19 10:07 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-19 17:08 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-16 13:01 +0100
Re: IPv6 Hardware Firewall Marco Moock <mo01@posteo.de> - 2022-02-16 19:12 +0100
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-17 09:12 +0100
Re: IPv6 Hardware Firewall Grant Taylor <gtaylor@tnetconsulting.net> - 2022-02-17 10:31 -0700
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-17 21:21 +0000
Re: IPv6 Hardware Firewall David Brown <david.brown@hesbynett.no> - 2022-02-18 09:25 +0100
Re: IPv6 Hardware Firewall meff <email@example.com> - 2022-02-11 10:28 +0000
Re: IPv6 Hardware Firewall Dan Purgert <dan@djph.net> - 2022-02-11 10:56 +0000
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-12 00:36 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-12 10:56 +0100
Re: IPv6 Hardware Firewall Roger Blake <rogblake@iname.invalid> - 2022-02-14 02:15 +0000
Re: IPv6 Hardware Firewall Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-14 08:52 +0100
Re: IPv6 Hardware Firewall jrg <jeff.g.group@att.net> - 2022-02-15 09:16 -0800
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Mike Mocha <mocha@mailexcite.com> |
|---|---|
| Date | 2022-02-09 08:16 +0000 |
| Subject | IPv6 Hardware Firewall |
| Message-ID | <VLKMJ.19775$iK66.8601@fx46.iad> |
I noticed something interesting the other day. If you are a typical home user with cable or DSL Internet service, and your provider gives you native IPv6 addresses and you desire to firewall the devices on your home network; since IPv6 is not using NAT, every device behind your router gets a unique IP address, so you basically have to either close down all IPv6 ports at the main router, OR open all IPv6 ports at the router, and then run a software firewall on each device on the network! This is not practical or possible on many devices (gaming consoles, smart phones, IoT devices, etc). I can prove this by opening and closing the IPv6 firewall settings on my provider's router. It's different with IPv4 of course. With IPv4, you only have one IP address for ALL the devices on your network. So you can setup the firewall to forward specific ports, and then setup services on individual devices using those ports. The point of this post, and my question, is there any consumer grade router available that allows you to manage IPv6 ports on a device basis, such as by individual IP or MAC address? There must be, otherwise how can devices using IPv6 ever be effectively firewalled? If you want to expose only certain services over IPv6 (SSH for example) on one device in your network, how do you do this with consumer grade routers?
[toc] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-09 10:01 +0100 |
| Message-ID | <20220209100111.6b4b869a@ryz> |
| In reply to | #5018 |
Am Mittwoch, 09. Februar 2022, um 08:16:53 Uhr schrieb Mike Mocha: > I noticed something interesting the other day. If you are a typical > home user with cable or DSL Internet service, and your provider gives > you native IPv6 addresses and you desire to firewall the devices on > your home network; since IPv6 is not using NAT, every device behind > your router gets a unique IP address, so you basically have to either > close down all IPv6 ports at the main router, OR open all IPv6 ports > at the router, and then run a software firewall on each device on the > network! This is not practical or possible on many devices (gaming > consoles, smart phones, IoT devices, etc). It is only a security issue if a service listens on a TCP or UDP port. If that is the case the problem is not IPv6, nor a missing firewall, it is the device that runs a software that listens on the TCP/UDP port. > I can prove this by opening and closing the IPv6 firewall settings on > my provider's router. It's different with IPv4 of course. With > IPv4, you only have one IP address for ALL the devices on your > network. So you can setup the firewall to forward specific ports, > and then setup services on individual devices using those ports. For IPv4 with stateful NAT44, you have to enable a static NAT rule (called port forwarding). Stateful NAT44 acts like an SPI firewall. If you additionally operate a firewall, you also need to create a specific rule there. For IPv6 without NAT, you only need to configure your firewall, if enabled. > The point of this post, and my question, is there any consumer grade > router available that allows you to manage IPv6 ports on a device > basis, such as by individual IP or MAC address? There must be, > otherwise how can devices using IPv6 ever be effectively firewalled? > If you want to expose only certain services over IPv6 (SSH for > example) on one device in your network, how do you do this with > consumer grade routers? I know that some cable modem routers from Technicolor offer that possibility. The default is an enabled SPI firewall. You can either disable it completely or allow certain ports for IPv6 addresses. The German Fritz devices also support such a firewall. If you want a secure network, make sure not network services are running you don't want. Additionally, you can use a normal hardware firewall that is fully configurable.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-09 11:18 +0100 |
| Message-ID | <su04d7$1c1hl$1@news1.tnib.de> |
| In reply to | #5019 |
Marco Moock <mo01@posteo.de> wrote: >If you want a secure network, make sure not network services are >running you don't want. Devices that allow you to control that are seldomly found. Not even Windows gives this kind of control. Smart TVs, Gaming Consoles etc don't either. >Additionally, you can use a normal hardware firewall that is fully >configurable. Name one consumer grade "hardware" firewall, please. I bet it does things in software still. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Mike Scott <usenet.16@scottsonline.org.uk.invalid> |
|---|---|
| Date | 2022-02-09 15:17 +0000 |
| Message-ID | <su0ltj$gv4$1@dont-email.me> |
| In reply to | #5019 |
On 09/02/2022 09:01, Marco Moock wrote: ...... > > If you want a secure network, make sure not network services are > running you don't want. Not a useful comment. I run various services for LAN use that I'd not want exposed to the world. You can't just turn off nfs, ssh, ntp, etc; while some LAN devices like cameras and TV etc can be safely assumed to be unchangeably insecure. MH's comment re fritzbox is useful to know (thank you!): I've been wary about dipping a toe into IPV6 precisely because of the risk of service exposure. The fritzbox (I have an ISP-supplied one) seems quite a handy gizmo, albeit poorly documented in places. > Additionally, you can use a normal hardware firewall that is fully > configurable. > -- Mike Scott Harlow, England
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-09 16:39 +0100 |
| Message-ID | <20220209163922.2794d89d@ryz> |
| In reply to | #5022 |
Am Mittwoch, 09. Februar 2022, um 15:17:06 Uhr schrieb Mike Scott: > Not a useful comment. I run various services for LAN use that I'd not > want exposed to the world. You can't just turn off nfs, ssh, ntp, > etc; while some LAN devices like cameras and TV etc can be safely > assumed to be unchangeably insecure. If they don't support ACLs where I can restrict the access to my subnet I let them only listen on an IPv6 ULA prefix that isn't being routed in the internet. > MH's comment re fritzbox is useful to know (thank you!): I've been > wary about dipping a toe into IPV6 precisely because of the risk of > service exposure. The fritzbox (I have an ISP-supplied one) seems > quite a handy gizmo, albeit poorly documented in places. Also IPv6 with EUI64 or privacy extension addresses isn't that easy to guess, so the attacker first need to find out the address of the device and with a /64 net that is quite a lengthy task.
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-09 11:16 +0100 |
| Message-ID | <su04a3$1c1h1$1@news1.tnib.de> |
| In reply to | #5018 |
Mike Mocha <mocha@mailexcite.com> wrote: >The point of this post, and my question, is there any consumer grade >router available that allows you to manage IPv6 ports on a device basis, >such as by individual IP or MAC address? The AVM Fritzbox can of course do this. It even has sensible default: Outgoing accepts everything, incoming blocks everything. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-09 16:54 +0000 |
| Message-ID | <slrnt07sg7.5ru.dan@djph.net> |
| In reply to | #5018 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Mike Mocha wrote:
>
> I noticed something interesting the other day. If you are a typical home
> user with cable or DSL Internet service, and your provider gives you
> native IPv6 addresses and you desire to firewall the devices on your home
> network; since IPv6 is not using NAT, every device behind your router
> gets a unique IP address, so you basically have to either close down all
> IPv6 ports at the main router, OR open all IPv6 ports at the router, and
> then run a software firewall on each device on the network! This is not
> practical or possible on many devices (gaming consoles, smart phones, IoT
> devices, etc).
Proper IPv4 and IPv6 firewalls look nearly identical (IPv6 addresses are
just longer). Only real difference is that because you have to to NAT
with IPv4 in addition to the firewall rules, most routers have a
"simplified" user interface (usually "port forwarding" or something to
that effect). Depending on make/model, you may or may not be able to
set individual NAT/Firewall rules.
In either event, the "IPv4 Port Forwarding" UI does two things:
1. Set up a new DNAT rule for destination (WAN_IP, Wan Port) gets
translated to (LAN_IP[,LAN_PORT])
2. Set up a new firewall rule for destination (LAN_IP[,LAN_PORT])
ACCEPT
An IPv6 firewall rule merely needs to be setup for
"prefix::abcd:1234,PORT" ACCEPT.
In either event, both firewall inbound chains will (should) look
something like this:
firewall_inbound {
rule 1 - accept established / related traffic
rule 2 - drop invalid packets
rules {3-N} - custom rules ("accept port 80/443 to webserver IP")
rule 10000 - drop everything else }
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmID8gcACgkQbWVw5Uzn
KGC+aQ/+OnsArTblZOieNr4KPL+W5h2aDDimZtIbb90uEeEUgTPDkvRJi27XXtOX
O9DERnF/6dvNGEQQLRm+lcPWx2VzwBNiWwlVuEy6hl4y0ByRSDmPOL9F8IDOBmnq
oZeBsr1XyG/5W5Yck74D1DpOCpNl6DDuelHH3CCTzU/+jA1wtrddRsjmJsaXbidZ
6KodjUeYgw92ZN9zL3Nfva2pQMsVuIxuWeDnsUxDa+GTX7Cr2L4cmmK4elQB9zMc
YpIoDfgt6UgExRq9NwhxMNGtxwhYXtmk4pqaJnEFlzoLkiKieBLi/3KCT7BWpAA2
dTmMAl6Fp1z0F+QJjqL12yI+ovvcYp/445dAeawJJ029wIfReWg6NYBsezyiqThH
Eo/3Sve9Gp4jdQ2+Jytz/LKJl7SogrPJlcoMRO1sH6tR3PRynCmPA5n1KuyzSwjh
QSjzd4SWIkpd7G02KF4KaYVZFQNdPeQSUppZfPTnAZ0WdufPF5cIervaChwkgkBq
d/MdNen2qTh6JcYtX9nWS1THgM7SBBdBVKes2XLyMs55QbZEyKGacObmnS9POVWS
SB6xN1h1ryV2Py3n2q5VBpvjAlzKU33KBJXuxixtZ7XD6JISzNOQ/BU24CDyesuO
ymusm8TeKSEZsRvpwYhGmemPb4+tZM2muaXgzb2p4rlsc/rfVeM=
=oOCF
-----END PGP SIGNATURE-----
--
|_|O|_| Github: https://github.com/dpurgert
|_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
|O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-09 17:57 -0700 |
| Message-ID | <su1nsm$43a$2@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5018 |
Somebody's got to say it, so it might as well be me. On 2/9/22 1:16 AM, Mike Mocha wrote: > since IPv6 is not using NAT IPv6 NAT works perfectly fine. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-10 08:27 +0100 |
| Message-ID | <20220210082754.6488362e@ryz> |
| In reply to | #5025 |
Am Mittwoch, 09. Februar 2022, um 17:57:06 Uhr schrieb Grant Taylor: > Somebody's got to say it, so it might as well be me. > > On 2/9/22 1:16 AM, Mike Mocha wrote: > > since IPv6 is not using NAT > > IPv6 NAT works perfectly fine. But it is not recommended to use it. It creates additional latency and stateful NAT is a relict from IPv4. If you want the "security" feature of NAT, use an SPI firewall.
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 10:59 -0700 |
| Message-ID | <su3jp3$7qe$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5027 |
On 2/10/22 12:27 AM, Marco Moock wrote: > But it is not recommended to use it. Agreed. Though a recommendation against something doesn't mean that doesn't exist. If anything, the recommendation against something is supporting that it does exist. }:-) > It creates additional latency True. Though many things create additional latency. > stateful NAT is a relict from IPv4. I could argue that TCP is even more of a relic from IPv4. > If you want the "security" feature of NAT, use an SPI firewall. NAT can be multiple things. Some of them provide zero security. A Stateful Packet Inspection firewall is independent of NAT. SPI /does/ provide security. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 19:14 +0000 |
| Message-ID | <slrnt0ap23.5ru.dan@djph.net> |
| In reply to | #5032 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > NAT can be multiple things. Some of them provide zero security. I'd argue no implementations of NAT (by themselves) provide any security. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFZEMACgkQbWVw5Uzn KGCi/w/+LpseReJA1MVa6Zszb5FuIZj34arTNrWeCIppUFv9gA5ku3u4EDKIVGS5 seB1o9NwqV1PlHI3TKeqCMaiwg3nJDwnsMYfpwbStjSSgebAAPJW9Iqna6Xl4ZHW mSd/7hcT8W8uedrtcIR7067xZZwTMI5s0h+gn2Z68G75a661CyAWf57WzELXF9Hx UD+kzCmdooXZqJs3gD2A8KnqqPlPuVWUfiiS01Cpa4TkzSEb4lL8SFBLi8q2NKTj iiKNPfG8OqEQMLn3de5QSTpOYDWHvN/sUFww4XmWxF2TNe8K842larfNK2NO9vxt 6WFztb+1suqsexepvhdbpItUiEPGfxTfW3oKPxV8pjzyLkdIwC36tFlJ8GrwCmmr iBccIodZbb1nHOQjKwXjmBrHA19s/bvRjg4kLkv22kBiHEEhT/6lgQC+hZoVvU77 rt6oc7TGSB+1rGasc7WZQhrV4DuKBC/gMDIWKxMpWX4yJyOasD2ZI7P/nKj38FEL rM8Xqchy/FdWfnSZRgkZo2MoIrvPg515ynoP0UvECNEeEgF5SfWVS21X3O8API72 T9j17Fr2eADcNoIhgYJwnM/ThrImW79e2Hjv/EWY8rHMx5OUPGwbeB0t1TQxAieJ 8Sgrd/b6FUo7ze47+SW9198/f9PJs+RDdS4f1uRHK5/G8MgEggQ= =VlUI -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Marco Moock <mo01@posteo.de> |
|---|---|
| Date | 2022-02-10 20:39 +0100 |
| Message-ID | <20220210203935.3a4fc97a@ryz> |
| In reply to | #5036 |
Am Donnerstag, 10. Februar 2022, um 19:14:32 Uhr schrieb Dan Purgert: > I'd argue no implementations of NAT (by themselves) provide any > security. stateful NAT (regardless if NAT44/NAT64) provides implicit seceurity. It is like an SPI firewall, without a static NAT rule (port forwarding) you can't access the devices behind the NAT.
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 20:25 +0000 |
| Message-ID | <slrnt0at6b.5ru.dan@djph.net> |
| In reply to | #5038 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Marco Moock wrote: > Am Donnerstag, 10. Februar 2022, um 19:14:32 Uhr schrieb Dan Purgert: > >> I'd argue no implementations of NAT (by themselves) provide any >> security. > > stateful NAT (regardless if NAT44/NAT64) provides implicit seceurity. > It is like an SPI firewall, without a static NAT rule (port forwarding) > you can't access the devices behind the NAT. > The "Stateful" part of "Stateful NAT" is the firewall sitting immediately behind DNAT, checking to see if packets have valid states. No firewall = no security. "Port forwarding" (as implemented in most,if not all routers) is just a "quick and dirty NAT+Firewall rule" shortcut... -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFdMoACgkQbWVw5Uzn KGAGtg/+KmtDl26JA9KCT+Qr4E1vm94JF/IesB4vq2KKXd1aWIwnKKAwWDe3ftBv ahS180/S/WmRjYzM1WHVP94PLy0k2lC1V+JFnq7NEBKca5qtSXyC2lSGm/1CwhWV UfXP430ZSfFMjsbzU77rL034w63AP4aYkurFmL2FLYTrS9liqcw1aRvelrEGWz/i LB0IAI4LvSDFDept8etrkj3KO0/+HZ43MkO4drcFrFKYyLkBXRhWMbKCkjZIEpsY 9/QD4pIZAbBvCfqrQttc/ST4Ya+gLQCqBZy0kR0DG1pXQZGwRhCIBl2j4hJN0t3q bopgcF8ZJNkrKsUEYj3S4UHXW95r3UP7oxvSjOW5/kpWoBiAjwE6wg95YnsKR1TH HRoxn16xVCQB19z78gCWTwt5Pq79JbzUC3Bt1d/B31kysQFBLZ5BTSEopYdS59Sh mRzChnPU48h6X5FgId5bL0VfYeoGIOAHyzz6RQGRbRMBDCGDffdXdFKPQeMnQwBC xWSoS4IgvgoyBiJabpCCoE73AVg1gHCUl8/VbbkseG5uypLnAHauoX4FfrDgmy8G QPDPcATCb6A6Vyhf3pEeMlLjBLoMVMC77B6JhPyUdteF9H3gpurZSJVESoGmEW11 y7LI7X+2+aXKT72s3SsFmkWVdH0NJE+NO3m5NnlLZ/mH+mXq/BI= =duJD -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 14:45 -0700 |
| Message-ID | <su4120$9h0$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5041 |
On 2/10/22 1:25 PM, Dan Purgert wrote:
> The "Stateful" part of "Stateful NAT" is the firewall sitting
> immediately behind DNAT, checking to see if packets have valid states.
>
> No firewall = no security.
I disagree.
To me, Stateful Packet Inspection and NAT State are two different
things. Especially considering that iptables uses two different
configurations for SPI and NAT.
Admittedly, the two features may share quite similar dependencies.
When I think of Stateful NAT / Masquerading in Linux, I think of a
connection table that is populated as packets egress through the router.
Said entries contain (at least) the incoming source & destination IP &
port pair and the outgoing source & destination IP & port pair. Wherein
one or more of the source / destination IP and / or port is modified.
So when 192.0.2.3/24 sends a connection to 203.0.113.234, the following
entry is created as the packet is NATed on it's way out.
1) Client sends and router receives: 192.0.2.3:45678 / 203.0.113.234
2) Router creates the following NAT state entry.
IS 192.0.2.3:45678
ID 203.0.113.234:443
OS 198.51.100.200:12345
OD 203.0.113.234:443
{Inside,Outside}{Source,Destination}
3) Router translates the packet and routes it - sends:
198.51.100.200:12345 / 203.0.113.234:443
4) Server receives 198.51.100.200:12345 / 203.0.113.234:443.
5) Server does it's thing.
6) Server sends 203.0.113.234:443 / 198.51.100.200:12345
7) Router receives 203.0.113.234:443 / 198.51.100.200:12345
8) Router finds a matching NAT state entry.
9) Router translates the packet and routes it - sends:
203.0.113.234:443 / 192.0.2.3:45678
A) Client receives 203.0.113.234:443 / 192.0.2.3:45678
Any traffic coming into 198.51.100.200 that doesn't have an associated
NAT state entry is simply routed to processes running on the router's
local TCP/IP stack.
As such, the lack of NAT state entries means that the packet goes to the
router, where the port is likely closed. Thus the connection inherently
stops because there is no place for it to go.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
or
iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source
198.51.100.200
No additional rule(s) are needed to allow NATed traffic to flow.
(Presuming that there aren't other rules prohibiting it.)
Conversely, Stateful Packet Inspection tracks the state of connections
and /explicitly/ takes action based on the connection state.
SPI uses similar connection state information, but for a different
purpose. It is also interfaced with a different way.
iptables -t filter -A INPUT -i ppp0 -m state --state ESTABLISHED -j
ACCEPT
SPI will depend on other rule(s) or built in chain default policy to
block traffic.
Both NAT / Masquerade and SPI work equally well with any combination of
non-globally routed and globally routed IPs.
But, importantly, pure NAT / Masquerade will function without any other
firewall rules / configuration while blocking connections that aren't in
the NAT state table.
Does NAT behave similarly to SPI? Yes. Is NAT dependent on SPI? No.
There was a time -- back in early 2.4 kernels -- when you could have NAT
/ Masquerade support in the kernel without SPI support in the kernel.
Or vice versa, SPI support in the kernel without NAT / Masquerade
support in the kernel.
NAT / Masquerade and SPI are really two completely different things in
the Linux kernel.
> "Port forwarding" (as implemented in most,if not all routers) is just a
> "quick and dirty NAT+Firewall rule" shortcut...
Now we delve into what is "port forwarding".
On one level, "port forwarding" is simply a (Destination) NAT rule.
There is no inherent /requirement/ for any other rules to do DNAT.
However, there are /usually/ other firewall rules that would match and
block the DNATed traffic. As such, there needs to be a rule to allow
the DNATed traffic through the firewall (nominally the FORWARD chain in
the filter table).
It's entirely possible to DNAT traffic as it passes through a router
wherein the firewall wouldn't block it. E.g. you allow traffic form the
world (0/0) to your DMZ hosts (198.51.100.0/24). You implement a DNAT
rule to alter traffic to your old web server's IP address to go to the
new web server's IP address.
# iptables -t nat -A PREROUTING -d 192.51.100.200 -j DNAT
--to-destination 192.51.100.100
Finally, NATing / Masquerading really translate source and / or
destination IP and or port /before/ the Linux kernel uses traditional
/routing/ to handle the packet. Hence why you do DNATing in the
nat:PREROUTING chain and SNATing in the nat:POSTROUTING chain.
--
Grant. . . .
unix || die
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 22:24 +0000 |
| Message-ID | <slrnt0b45h.5ru.dan@djph.net> |
| In reply to | #5048 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > On 2/10/22 1:25 PM, Dan Purgert wrote: >> The "Stateful" part of "Stateful NAT" is the firewall sitting >> immediately behind DNAT, checking to see if packets have valid states. >> >> No firewall = no security. > > I disagree. > > To me, Stateful Packet Inspection and NAT State are two different > things. Especially considering that iptables uses two different > configurations for SPI and NAT. [...] Yes, but an unsolicited packet that doesn't trigger NAT rules can (and in many cases will) still be forwarded by the router. Granted, this isn't likely to happen across the internet[1]; but say between two local subnets that one is subject to NAT before going upstream (e.g. that dirty hack I've had to do on occasion because some vendor-supplied appliance will only ever work as 10.1.1.2, and oh no, you can't change its IP, what do you mean you'd ever not use 10.1.1.0/8 on your office LAN ... or ever want to use TWO of these in the same facility?!) I think it's more a case of we're looking at the same coin from two different sides (and I wholly agree with the direction you presented in the bits I snipped). [1] I'm only refraining from saying it's impossible across the internet, lest someone come back with contrary examples ;) >> "Port forwarding" (as implemented in most,if not all routers) is just a >> "quick and dirty NAT+Firewall rule" shortcut... > > Now we delve into what is "port forwarding". [...] Maybe the conversation diverged somewhere, and I hadn't noticed -- I was under the impression that the phrase "port forwarding" was being used strictly in the context of general consumer "whole-home-gateway" devices (either supplied by one's ISP or picked up from AMZN/BestBuy/etc); so literally the "simplistic" interface that consumers are expecting to (1) Insert any necessary DNAT (and potentially PAT) rule AND (2) Insert the corresponding firewall rule in int INPUT chain Rather than the general sense of the phrase you are presenting in the bit I snipped out. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFkK4ACgkQbWVw5Uzn KGDJAQ/+IcEfIhMzNmg4Ry6nVrOdo9YgV/1Xwf46WMVgznZCM5h/SDXwZ/WJzWGc Y8qZAcPdE/yUsM5wSFXo2xWax2/j6lHZ5L1GRzh4WZy8hYkDh+e1XWcmBnX63184 PecfWae2oC6A0hM9QBF7s1ztMJXlXXfIe/SjCaCOr9iQ7nMehWfbtQFYgTGEFJMz VDRHVusWL3SqiYO0yJ8u6clb6FthWwoMnhN92hub8XdpA4KBAUYtybesJwVWMNAc AHp0k+Xr4CnqsvzVXb3SHpLsC6CV6ZW5oxpqVmgQ/mIyWiGPA3tIyOxxjDZyq8U0 RMywFkKwgy7QSYZNSqd92a74ilBxjfIgTok28S2xL+P9LFtIabmUTwCJK8E2e+qj isoYH0G/OVyxkmRelx8K8Op3v6wv7QbKEiQgcWEEorQS6kw/czu8lKv2qvQooX8e mcCxFkbmzbwxSgML77ja5KMTYcBYbo8VMl676n2bL/7wlZl6KrLiPJhquW3HOh6Y 25VknpxQFKMEnqG73DrVHaXwxRsypfRYjl2H7zpJIgNSQB3cmGWcwNPH0kAcAeSR VHhbISX9GveSuRU1Pk0cu6SBCldZFkWRF7U81kG+F5u+Mnl+N9USkYQbx1kNVJXi DT0+IzC+uDtYyYxq8mCJ7LZB9qRu0hvb9dVlO0FQwLD+EjJ0cTA= =9HsS -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 12:49 -0700 |
| Message-ID | <su3q70$h3i$1@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5036 |
On 2/10/22 12:14 PM, Dan Purgert wrote: > I'd argue no implementations of NAT (by themselves) provide any > security. This gets into theological discussions / debates about what NAT is and is not. I see no way that Stateless NAT /by/ /itself/ can provide security. (Save for potentially only applying to specific source & destination IP pairs. I know you know what I mean here.) I think that Stateful NAT that dynamically maps between internal and external IP(s) & port(s) probably provides some inherent security in the fact that incoming connections will fail if there isn't associated NAT state data to support the connection. I'd enjoy such a theological discussion / debate. But I think it's very much it's own independent topic. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2022-02-10 20:48 +0000 |
| Message-ID | <slrnt0auiv.5ru.dan@djph.net> |
| In reply to | #5040 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Grant Taylor wrote: > On 2/10/22 12:14 PM, Dan Purgert wrote: >> I'd argue no implementations of NAT (by themselves) provide any >> security. > [...] > I think that Stateful NAT that dynamically maps between internal and > external IP(s) & port(s) probably provides some inherent security in the > fact that incoming connections will fail if there isn't associated NAT > state data to support the connection. I must have a wire crossed somewhere, as I'm fairly certain that it's more the firewall behind things that keeps unwanted traffic from making a mess of things, even with conntrack in the mix. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmIFel8ACgkQbWVw5Uzn KGD/Aw/9GMg6ApPtYYO0VMWYjSRQaKVwLNs5P40FV038yjEyJcDaXHCov/OKlrus EmneBV5Y0vIXDdk5HNIOe7U9P3SLZUWt7GoOmG4tcsnftF2+c9+qro8hedNQk8Kw 5x6KpHhoPxT3MyxNtohr5tufrl4ao1yQQ1UL2BCekml3bktIQY7/wI97YAJGTlWn 3BzW6OfDphNEbJstWs6hpKr236d/iAaGe3PGW5FR4CGWo4wd3pPnvADl43ZwS9xW cMGf18BewZrXu5RIiu7gBjz+2bd8ZjBmi1fd/xlY7wIpmdhH0Nd6LM+MK/ipdrAC 4/ef6GZGC3sBvyuU6Xpu5/8CfE7VYq4i96PtUc6HyYm+/d8wHHi564q9Fi5sm3/W +X2wgL0diTMP0jYlDBbjzTAhei5Uf5tKhjoOuDseZKF2fE+pKuHp9I9qxZR9KCRF 04lS0GnHK6aWdZeG9feg1T3yuivdTj6q+VExlOU8ZjndGTOzdrRy4JosBSOINvLN 95HlsqCC1xe5LiAw6IQBcK+A8K0MFLaDBvwtKcrWW3nbXUWzHNf+IvGn5YKDUoiQ oJe3MslHmhupxxFN463gmNNEUK7J/81969rNdyY55VD1wsHOHtafsML3exOnwlRy adLiV+WD02x1gXNJKm/tIoV3Mi0TWbLiUW4XiMr5j8Sx9vOmXUk= =QQEN -----END PGP SIGNATURE----- -- |_|O|_| Github: https://github.com/dpurgert |_|_|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 |O|O|O|
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 14:46 -0700 |
| Message-ID | <su413p$9h0$2@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5044 |
On 2/10/22 1:48 PM, Dan Purgert wrote: > I must have a wire crossed somewhere, as I'm fairly certain that > it's more the firewall behind things that keeps unwanted traffic from > making a mess of things, even with conntrack in the mix. Nope. See the my reply to your other comment for a much more detailed explanation. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-02-10 10:08 +0100 |
| Message-ID | <su2kma$1gat9$1@news1.tnib.de> |
| In reply to | #5025 |
Grant Taylor <gtaylor@tnetconsulting.net> wrote: >Somebody's got to say it, so it might as well be me. > >On 2/9/22 1:16 AM, Mike Mocha wrote: >> since IPv6 is not using NAT > >IPv6 NAT works perfectly fine. But you don't need to use it, as long as the network is sane. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Grant Taylor <gtaylor@tnetconsulting.net> |
|---|---|
| Date | 2022-02-10 11:01 -0700 |
| Message-ID | <su3jso$7qe$2@tncsrv09.home.tnetconsulting.net> |
| In reply to | #5029 |
On 2/10/22 2:08 AM, Marc Haber wrote: > But you don't need to use it, as long as the network is sane. Let's agree to disagree without getting into minutia. Remember, port forwarding -- which is a thing in IPv6 -- is at it's roots NAT. There are definitely uses for port forwarding in IPv6. -- Grant. . . . unix || die
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.os.linux.networking
csiph-web