Re: IPFW on CURRENT: NAT forwarding exposes internal IP!

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Thu, 29 Sep 2016 15:24:11 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am Thu, 29 Sep 2016 16:00:10 +0300
Daniel Kalchev <daniel_at_digsys.bg> schrieb:

Yes, your are right :-)

Yes, I'm wrong, it is not NAT :-(

Thanks a lot, 

Oliver
> It looks like your httpd server is doing a redirect to your internal IP address, which
> it thinks is it’s ServerName. Don’t think NAT has anything to do with it.
> 
> Daniel
> 
> > On 29.09.2016 г., at 15:47, O. Hartmann <ohartman_at_zedat.fu-berlin.de> wrote:
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > 
> > Despite other problems with IPFW and its documentation regarding NAT, I face a serious
> > and disturbing problem.
> > 
> > I run a NanoBSD based router/firewall project of my own, running CURRENT (FreeBSD
> > 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the filter of my
> > choice, since it is FreeBSD's native. I also use In-kernel-NAT as well as pppoed/ppp.
> > The modem is connected to a dedicated NIC, the pppoe-traffic is transported via tun0
> > - I think this is the usual stuff.
> > 
> > The IPFW has this NAT rule:
> > 
> > ${fwcmd}        nat 1 config if ${if_isp0} \
> >                        log \
> >                        reset \
> >                        same_ports \
> >                        redirect_port tcp ${server_gate}:22 22 \
> >                        redirect_port tcp ${server_www}:80 80 \
> >                        redirect_port tcp ${server_www}:443 443 \
> >                        redirect_port tcp ${server_refdb}:9734 9734
> > 
> > server_www is assigned to a non-official IP, 192.168.10.10.
> > 
> > if_isp=tun0, tun0's IP is given by the provider, I use net/ddclient as the updater
> > for a dynamic DNS account.
> > 
> > I use an internal DNS server, which resolves 92.168.10.10 to a certain name. I also
> > use self signed SSL certicates, just for completeness of this information.
> > 
> > Connecting from the outside world to my dynDNS domain triggers Firefox or any other
> > browser to compalin about the self signed SSL certificate - as usual, but then, adding
> > it, suddenly the domain name (say: www.blabla.org) is replaced by the internal IP I
> > delegate any access on ports 80 and 443 to.
> > 
> > What happens here? I consider this a bug, I never saw this on our Linux servers
> > running a similar setup (forwarding, BIND 9.10/BIND 9.11).
> > 
> > Thanks,
> > 
> > Oliver
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2
> > 
> > iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3
> > yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp
> > ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04
> > 9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD
> > 20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc
> > K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=
> > =oMGL
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current

> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"  
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current

> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX7RX7AAoJEOgBcD7A/5N85rAH/jbwR0yd1bE0a9OIukfJyf2Y
3s+O+GQakxZJmYD6vv+k+6M2qD9TFsrCHmHylNfsV5gBirFZe6gEHRibXnvnlQxy
JmXniK2o/HXl/NDxEKTshqX6xtS+xeow7IhObCG42OaZrxUdKgX3qfgY13VKEVM1
9NdLv0EE0veK+EnxmxnBSDl2h5wV69pK1Ra+iLSSfYeO+VMMH2eUK6jbh/S4cB5h
AJ4oK08by4SNOsovMwtKLF+U1NHaDuHKWG92rXU1mYN/M3rqtVgVpq040tOVDFpC
Nylhj4e1XRnM/U3Y7VBztfTN4EXGRK8D+m1fOXGiPnet30vhd3kYFRhTF5vnf1U=
=LumJ
-----END PGP SIGNATURE-----
Received on Thu Sep 29 2016 - 11:24:18 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:08 UTC