The following reply was made to PR kern/159353; it has been noted by GNATS.
From: Svatopluk Kraus onw...@gmail.com
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/159353: [netinet] [patch] conditional call of
ifa_del_loopback_route()
Date: Tue, 9 Aug 2011 12:55:42 +0200
This PR can be
Hi all,
I have set up a new router for my network, with separated DMZ zone for
my internet servers. I'd like computers from my LAN to be able to
connect to DMZ zone.
My ISP provided me some public IP's, so right now configuration looks
like this:
Router with 4 NICs:
#public ISP
On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote:
Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I
really can connect to host 192.168.0.10 etc.
The problem is that when I want to connect from my 10.0.0.0/24 network (and
even from router) to any DMZ host,
W dniu 2011-08-09 15:09, Chuck Swiger pisze:
On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote:
Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I
really can connect to host 192.168.0.10 etc.
The problem is that when I want to connect from my 10.0.0.0/24 network
On Aug 9, 2011, at 6:15 AM, Marek Salwerowicz wrote:
It's not working because you configured natd to work against traffic flowing
via vr3, but traffic from your LAN is coming via vr0. While you can change
natd to run against all traffic, it's much better to avoid re-writing purely
internal
W dniu 2011-08-09 15:26, Chuck Swiger pisze:
dummynet (or Altq, or whatever else you might be using) works fine with pure
routing config, yes-- you don't have to NAT traffic to do bandwidth control on
the router.
How it should be done?
Leave the aliases at my external interface, and then
On Aug 9, 2011, at 6:45 AM, Marek Salwerowicz wrote:
W dniu 2011-08-09 15:26, Chuck Swiger pisze:
dummynet (or Altq, or whatever else you might be using) works fine with pure
routing config, yes-- you don't have to NAT traffic to do bandwidth control
on the router.
How it should be done?
Old Synopsis: [patch] in_scrubprefix() - loopback route refcount malfunction
New Synopsis: [netinet] [patch] in_scrubprefix() - loopback route refcount
malfunction
Responsible-Changed-From-To: freebsd-bugs-freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Aug 10 00:27:54
On Mon, 8 Aug 2011 16:54:10 +0200 Ferdinand Goldmann wrote:
FG Hi!
FG I am trying to create a common resource pool for a certain application
using
FG CARP/HAST as described in [1]. However while testing my setup I ran into a
FG problem which I don't know how to fix or work around:
FG If
