Hi,
Adding this patch does make it work for me. There might be better ways to
do it. I have tested with ping and ssh. In ping's case, ping reported:
frag needed and DF set (MTU 1392)
In ssh's case I could see with tcpdump that the "need to frag (mtu 1392)"
was sent back and the next packet's
Hi,
What would the proper ipfw rules be to make nat work and properly get the
icmp too big packets back to a local host if the wan interface needs a
smaller mtu?
I'm using a FreeBSD machine as router/firewall, but its wan interface needs
a smaller mtu (1392) than the default ethernet mtu. I have
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213154
Graham Perrin changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Graham
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
Lutz Donnerhacke changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
Lutz Donnerhacke changed:
What|Removed |Added
Flags||mfc-stable13+,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
--- Comment #10 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=1883127de4888b2a30a6cb51e8fb4bdf33b7f411
commit 1883127de4888b2a30a6cb51e8fb4bdf33b7f411
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
--- Comment #9 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=3a96a25da8614d27f717ba8d29d32bafb04a70e8
commit 3a96a25da8614d27f717ba8d29d32bafb04a70e8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
--- Comment #8 from Lutz Donnerhacke ---
May you please test your problem against 14-CURRENT?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=d261e57deacb0d00d9e827447f235df83dda3e3a
commit d261e57deacb0d00d9e827447f235df83dda3e3a
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
--- Comment #6 from Lutz Donnerhacke ---
May you try to apply those patches, please?
https://reviews.freebsd.org/D30516
https://reviews.freebsd.org/D30536
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
Lutz Donnerhacke changed:
What|Removed |Added
Status|Open|In Progress
--- Comment #4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
Lutz Donnerhacke changed:
What|Removed |Added
CC||i...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
--- Comment #6 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=652908599b6fa7285ee60cb567b97e70b648ac29
commit 652908599b6fa7285ee60cb567b97e70b648ac29
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
--- Comment #5 from 0xcdcdc...@gmail.com ---
I installed the patched ipdivert.ko and enabled the sendfile for nginx.
A few hours passed, but still no panic.
I will report it if it occurs.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
--- Comment #4 from 0xcdcdc...@gmail.com ---
Thanks for your advices.
I disabled the sendfile for nginx and confirmed that it works stably.
I'm building a kernel with the patch you provided, so I'm going to apply it and
check it out.
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
--- Comment #3 from Joshua Kinard ---
This might be related to the issue I reported in Bug #255104, where I get
random crashes/panics shortly after activating a divert(4) rule in my IPFW
firewall to route packets to Snort for inline
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
--- Comment #2 from Andrey V. Elsukov ---
Created attachment 224248
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=224248=edit
proposed patch (untested)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255164
Mark Linimon changed:
What|Removed |Added
Keywords||panic, regression
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
l...@donnerhacke.de changed:
What|Removed |Added
CC||l...@donnerhacke.de
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192888
Tom Jones changed:
What|Removed |Added
CC||t...@freebsd.org
--- Comment #1 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224231
Andrey V. Elsukov changed:
What|Removed |Added
Resolution|--- |FIXED
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224231
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org
On 02/09/2017 20:46, Ian Smith wrote:
On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:
> I have a problem that seems to be a difference between ipfw/NAT
> behaviour in 10-Stable versus 11-Stable. I have two servers: one running
> 10-Stable and one running 11-Stable.
On Sat, 2 Sep 2017 11:44:51 +1000, Graham Menhennitt wrote:
> I have a problem that seems to be a difference between ipfw/NAT
> behaviour in 10-Stable versus 11-Stable. I have two servers: one running
> 10-Stable and one running 11-Stable. I'm using the same rule set on both
>
I have a problem that seems to be a difference between ipfw/NAT
behaviour in 10-Stable versus 11-Stable. I have two servers: one running
10-Stable and one running 11-Stable. I'm using the same rule set on both
(see below). It works correctly on 10-Stable but not on 11.
The problem is seen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719
smi...@nimnet.asn.au changed:
What|Removed |Added
CC||smi...@nimnet.asn.au
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719
--- Comment #1 from b...@kobyla.org ---
Adding the "not layer2" to ipfw nat rule helps to avoid this problem
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216719
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org
Hello!
freebsd-amd64
10.3-STABLE FreeBSD 10.3-STABLE #0 r308165M:
# ipfw nat 1 show
nat 1: icmp=3, udp=27, tcp=77, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 /
tot=107
11.0-STABLE FreeBSD 11.0-STABLE #0: Mon Nov 14 17:54:37
# ipfw nat 1 show
ipfw: Please specify action. Available: config
Здравствуйте, Freebsd-ipfw.
freebsd-amd64
10.3-STABLE FreeBSD 10.3-STABLE #0 r308165M:
# ipfw nat 1 show
nat 1: icmp=3, udp=27, tcp=77, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 /
tot=107
11.0-STABLE FreeBSD 11.0-STABLE #0: Mon Nov 14 17:54:37
# ipfw nat 1 show
ipfw: Please specify
d-ipfw@FreeBSD.org
Summary|ipfw nat single pass with |[patch] allow ipfw nat
|ipfw netgraph multi pass|single pass with ipfw
||netgraph multi pass
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211256
Andrey V. Elsukov changed:
What|Removed |Added
Assignee|freebsd-ipfw@FreeBSD.org
ession
Assignee|freebsd-standards@FreeBSD.o |freebsd-ipfw@FreeBSD.org
|rg |
Summary|FreeBSD 11 ipfw nat |ipfw nat tablearg
|tablearg|regression in FreeBSD 11
--
You are receiving thi
Hi,
I've hit a very interesting problem with ipfw-nat and local TCP traffic
that has enough TCP options to hit a special case in m_megapullup().
Here is the story:
I am using the following NIC:
igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086
rev=0x01 hdr=0x00
This looks mostly sensible. hm!
-a
On 13 January 2016 at 11:55, Karim Fodil-Lemelin
<fodillemlinka...@gmail.com> wrote:
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic that
> has enough TCP options to hit a special case in m_megapullup(). H
||anonymous.bug.report@gmail.
||com
--- Comment #2 from Colin anonymous.bug.rep...@gmail.com ---
You need to add the log keyword.
ipfw nat 1 config if igb1 log unreg_only reset
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180729
Nick Hibma n_hi...@freebsd.org changed:
What|Removed |Added
Status|In Discussion |Issue Resolved
Old Synopsis: ipfw nat show empty output
New Synopsis: [ipfw] ipfw nat show empty output
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Jul 26 21:47:32 UTC 2013
Responsible-Changed-Why:
Over to maintainer(s).
http
--- Original message ---
From: isp ml...@ukr.net
Date: 20 July 2013, 18:12:07
Hi! I have problems with displaing information about NAT states on
FreeBSD 9.1.
There is no information when I use `ipfw nat 1 show`
I have the same issue on my router 9.1-STABLE FreeBSD 9.1-STABLE #1
Hi,
Recently, I have switched from pf to ipfw. All works fine, except nat statistic.
When I type
ipfw nat show or ipfw nat 1 show nothing is on output.
FreeBSD xxx.com 9.1-STABLE FreeBSD 9.1-STABLE #0: Tue Apr 30 22:03:16 EEST 2013
wishmas...@xxx.com:/usr/obj/usr/src/sys/MY6 i386
Kernel
The following reply was made to PR kern/129093; it has been noted by GNATS.
From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= kes-...@yandex.ru
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/129093: [ipfw] ipfw nat must not drop packets
Date: Tue, 20 Dec 2011 20:38:52 +0200
ping or traceroute any ext host (by ipfw
nat) -- it's OK
# uname -a
FreeBSD proxy.yy.ru 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Mon Oct 3
19:19:30 MSD 2011 a...@xx.yy.ru:/usr/obj/usr/src/sys/ZZZ amd64
# ipfw nat show config
ipfw nat 7 config if vr0 log same_ports reset redirect_port tcp
Hello, Andrey V. Elsukov!
You wrote on 06.10.2011 at 13:38:
On 06.10.2011 12:29, Oleg Strizhak wrote:
After an investigation I've found out a very strange situation - it seems to
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't
rewritten/seen
Здравствуйте, Andrey V. Elsukov!
Вы писали 06.10.2011 13:38:
On 06.10.2011 12:29, Oleg Strizhak wrote:
After an investigation I've found out a very strange situation - it seems to
me, that ipfw nat drops
some (type 11?) icmp reply packets, whose udp request packets it hasn't
rewritten/seen
On 06.10.2011 14:42, Oleg Strizhak wrote:
Hello, Andrey V. Elsukov!
You wrote on 06.10.2011 at 13:38:
On 06.10.2011 12:29, Oleg Strizhak wrote:
After an investigation I've found out a very strange situation - it
seems to me, that ipfw nat drops
some (type 11?) icmp reply packets, whose
Synopsis: [patch][ipfw] natd globalport support for ipfw nat
State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 28 10:17:04 UTC 2011
State-Changed-Why:
Merged to stable/8. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=157867
Hi Guys,
IS there anyway to get ftp to work properly with ipfw and nat without opening
all high ports ? In linux I used to use a module that handled it for me.
Now im getting a deny log as:
Jul 19 11:49:54 bsd kernel: ipfw: 450 Deny TCP 192.168.1.99:51446
196.43.2.109:34049 out via rl0
Any
Synopsis: [ipfw] ipfw nat traceroute problem
State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 7 09:42:47 UTC 2011
State-Changed-Why:
Merged to stable/7 and stable/8. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
Synopsis: [ipfw] ipfw nat must not drop packets
State-Changed-From-To: patched-closed
State-Changed-By: ae
State-Changed-When: Thu Jul 7 09:43:23 UTC 2011
State-Changed-Why:
Merged to stable/7 and stable/8. Thanks!
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit
statements State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Tue Jun 28 05:29:45 UTC 2011
State-Changed-Why:
Can you still reproduce this on a supported release?
Or maybe you can test your rules
Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit statements
State-Changed-From-To: feedback-closed
State-Changed-By: ae
State-Changed-When: Sat Jul 2 19:42:05 UTC 2011
State-Changed-Why:
The submitter has reported that the problem is already fixed. Thanks!
http
Hi,
I try to use load-balancing with IPFW. I've 3 lines : 2 ADSL and 1 SDSL. I try
to loadbalance http trafic on ADSL1(192.168.7.1) and ADSL2(192.168.6.1).
My gateway has 4 network devices. 1 for each line (em 1 -192.168.5.10, em2 -
192.168.6.10, em3 -192.168.7.10), and one for local network
Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit statements
State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Tue Jun 28 05:29:45 UTC 2011
State-Changed-Why:
Can you still reproduce this on a supported release?
Or maybe you can test your rules
Synopsis: [patch][ipfw] natd globalport support for ipfw nat
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: ae
Responsible-Changed-When: Tue Jun 14 06:36:57 UTC 2011
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr
Old Synopsis: ipfw nat config does not accept nonexistent interfaces
New Synopsis: [ipfw] ipfw nat config does not accept nonexistent interfaces
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Jun 9 21:27:53 UTC 2011
Responsible
Synopsis: [ipfw] ipfw nat traceroute problem
State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:53:46 UTC 2011
State-Changed-Why:
Patched in head/.
http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
Synopsis: [ipfw] ipfw nat must not drop packets
State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:54:30 UTC 2011
State-Changed-Why:
Patched in head/.
http://www.freebsd.org/cgi/query-pr.cgi?pr=129093
Synopsis: [ipfw] mtr does not work if I use ipfw nat
State-Changed-From-To: feedback-patched
State-Changed-By: ae
State-Changed-When: Tue Jun 7 06:55:06 UTC 2011
State-Changed-Why:
Patched in head/.
http://www.freebsd.org/cgi/query-pr.cgi?pr=157379
The following reply was made to PR kern/157379; it has been noted by GNATS.
From: Andrey V. Elsukov a...@freebsd.org
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
Date: Mon, 06 Jun 2011 09:51:09 +0400
Hi,
Can you
Synopsis: [ipfw] ipfw nat must not drop packets
State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 06:57:40 UTC 2011
State-Changed-Why:
This seems to be a duplicate of kern/157379.
Can you confirm that proposed patch fixes this issue?
http://www.freebsd.org
Synopsis: [ipfw] mtr does not work if I use ipfw nat
State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 06:59:19 UTC 2011
State-Changed-Why:
Feedback requested.
http://www.freebsd.org/cgi/query-pr.cgi?pr=157379
Synopsis: [ipfw] ipfw nat traceroute problem
State-Changed-From-To: open-feedback
State-Changed-By: ae
State-Changed-When: Mon Jun 6 07:00:37 UTC 2011
State-Changed-Why:
Can you test this patch?
http://people.freebsd.org/~ae/ipfw_nat.diff
http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
The following reply was made to PR kern/122109; it has been noted by GNATS.
From: ten ten@gmail.com
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Mon, 6 Jun 2011 21:38:36 +0700
--000e0cd22f68002b4704a50c0f97
The following reply was made to PR kern/122109; it has been noted by GNATS.
From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru, a...@freebsd.org
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Fri, 03 Jun 2011 10:08:13 +0400
The following reply was made to PR kern/157379; it has been noted by GNATS.
From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, kes-...@yandex.ru
Cc:
Subject: Re: kern/157379: [ipfw] mtr does not work if I use ipfw nat
Date: Mon, 30 May 2011 15:23:34 +0400
This seems
Old Synopsis: mtr does not work if I use ipfw nat
New Synopsis: [ipfw] mtr does not work if I use ipfw nat
Responsible-Changed-From-To: freebsd-i386-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun May 29 23:40:09 UTC 2011
Responsible-Changed-Why:
reclassify.
http
The following reply was made to PR kern/122109; it has been noted by GNATS.
From: ten d...@211.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Mon, 18 Apr 2011 22:41:45 +0700
--20cf30563995a1b54304a1333ac0
Content
Synopsis: [ipfw] Problem with loading of ipfw NAT rules during system startup
Responsible-Changed-From-To: freebsd-ipfw-hrs
Responsible-Changed-By: hrs
Responsible-Changed-When: Wed Jan 5 01:05:33 UTC 2011
Responsible-Changed-Why:
Take.
http://www.freebsd.org/cgi/query-pr.cgi?pr=148928
|
|
|
webserver
192.168.1.121
how to use of this two gateways for my internal webserver with ipfw nat
i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can
webserver with ipfw nat
i want to know how can i use ISP2 adsl as ISP1 ( i mean if anyone put ISP1
(172.16.1.5) , ISP2 (10.0.10.15) to the browser , can see my internal
webserver page with two separated ISPs ) not load balance . i want to use
two ISPs at the same time .
do you REALLY have 172.16.1.5
Synopsis: [ipfw] ipfw nat does not follow its documentation
State-Changed-From-To: open-closed
State-Changed-By: ae
State-Changed-When: Fri Dec 10 05:26:02 UTC 2010
State-Changed-Why:
Merged to stable/8.
http://www.freebsd.org/cgi/query-pr.cgi?pr=145167
The following reply was made to PR kern/122109; it has been noted by GNATS.
From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru
Cc:
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Wed, 22 Sep 2010 01:24:40 +0400
Problem can
Synopsis: [ipfw] ipfw nat traceroute problem
Responsible-Changed-From-To: piso-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Sep 16 17:10:45 UTC 2010
Responsible-Changed-Why:
piso's bit has been returned.
http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
The following reply was made to PR kern/148928; it has been noted by GNATS.
From: Thomas Sandford freebsdu...@paradisegreen.co.uk
To: bug-follo...@freebsd.org, fmy...@gmail.com
Cc:
Subject: Re: kern/148928: [ipfw] Problem with loading of ipfw NAT rules during
system startup
Date: Sun, 12 Sep
Old Synopsis: Problem with loading of ipfw NAT rules during system startup
New Synopsis: [ipfw] Problem with loading of ipfw NAT rules during system
startup
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 25 17:48:11 UTC
firewall rules to restrict which local
ports are to be accessible for connections from the outside.
cheers, Ian
I remove option deny_in from nat configuration. But inbound packets not
passed to the
local services.
#ipfw nat show config
ipfw nat 1 config ip xxx.xxx.xxx.xxx
ext_if1
Ouch. It does look like nat is just swallowing the ssh packets on the
inbound pass .. these surely should appear again after NAT (unchanged).
# ipfw nat show config
ipfw nat 1 config ip xxx.xxx.xxx.xxx
# tcpdump -pn -i ext_if1 'host yyy.yyy.yyy.yyy'
14:12:48.885011 IP
Hello.
I am currently trying to replace pf with ipfw. NAT is the biggest
missing bit in my configuration.
I want to go with ipfw nat (libalias) because I've been told it works
fine with dynamic rules (unlike divert) - is that statement correct?
If yes, then could somebody point me to some
Old Synopsis: ipfw nat does not follow its documentation
New Synopsis: [ipfw] ipfw nat does not follow its documentation
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Mar 29 19:57:57 UTC 2010
Responsible-Changed-Why:
Over
Hi list,
I just wonder how hard it would be to implement a following list of features:
- ability to use proxy_rule statement in ipfw nat (natd -proxy_rule)
- ability to see actual content of libalias nat table (ipfw nat 1 show table)
- ability to use one aliasing table in multi nat instances
Old Synopsis: deadlock using multiple ipfw nat and multiple limit statements
New Synopsis: [ipfw] deadlock using multiple ipfw nat and multiple limit
statements
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 22 05:28:06
Old Synopsis: ipfw nat redirect_port buf is too small error
New Synopsis: [ipfw] [patch] ipfw nat redirect_port buf is too small error
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Feb 8 03:54:50 UTC 2010
Responsible-Changed
Unless I'm mistaken, there appears no way to cause ipfw's internal
nat mechanism to log dropped packets. This is a considerable loss
of functionality from using natd. Is there a reason for this?
- M
--
Michael Sierchio
+1 415 378 1182
PO Box 9036 Berkeley CA 94709 US
ku...@tenebras.com
of anything for IPFW / NAT
So, the question is, can this be done? I've seen one or two suggestions out
there giving a brief description of how to use the fwd command to send
packets to dans but unfortunately I am not smart enough to implement that
here.
Any help, thoughts, or references would
Synopsis: ipfw nat redirect_proto is broken
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: remko
Responsible-Changed-When: Sun Aug 2 09:52:25 UTC 2009
Responsible-Changed-Why:
Over to maintainer.
http://www.freebsd.org/cgi/query-pr.cgi?pr=137346
On Thursday 16 July 2009, Chuck Swiger wrote:
On Jul 16, 2009, at 12:19 PM, Dmitriy Demidov wrote:
Update about this issue.
There is somthing wrong with UDP pass through - ipfw nat makes it
bad cksum.
tcpdump receives local network traffic before the checksums are
computed (especially
Old Synopsis: ipfw nat must not drop packets
New Synopsis: [ipfw] ipfw nat must not drop packets
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Nov 23 18:02:44 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http
I have a problem at the scheme:
( gw ) - ( nat_router ) - ( https )
real.ip0real.ip1 10.19.90.110.19.90.2
If I use ipfw+natd on nat_router then redirect to https server and to
nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect
I have a problem at the scheme:
( gw ) - ( nat_router ) - ( https )
real.ip0real.ip1 10.19.90.110.19.90.2
If I use ipfw+natd on nat_router then redirect to https server and to
nat_router local address 10.19.90.1 is well, but if ipfw+nat - redirect
at Community Foundation Silicon Valley.
We welcome and value feedback and comments.
Please forward feedback to [EMAIL PROTECTED] and [EMAIL PROTECTED]
Download patch from http://caia.swin.edu.au/urp/sonata/downloads.html
Features of alias_sctp version 0.1:
- Basic configuration through ipfw nat
Synopsis: ipfw nat traceroute problem
Responsible-Changed-From-To: freebsd-ipfw-piso
Responsible-Changed-By: piso
Responsible-Changed-When: Wed Mar 26 20:32:04 UTC 2008
Responsible-Changed-Why:
Mine.
http://www.freebsd.org/cgi/query-pr.cgi?pr=122109
Synopsis: [patch] ipfw(8): ipfw nat has problems to show multiples nat rules
Responsible-Changed-From-To: freebsd-bugs-freebsd-ipfw
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Feb 16 14:08:59 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi
I'm having a bit of trouble backporting 7.x to 6.x, 6.2 Release
specifically. Before I continue down this road, in the name of not
re-inventing the wheel twice, does anyone already have a current patch
which will work on 6.2 ? Thank You!
AFAIK no.
--
bye,
P.
On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
I was recently testing the in kernel nat patch, which is an
absolutely wonderful addition in my opinion. I have however run
into one issue, when for example I do the following :
ipfw nat 10 config ip 2.2.2.2
On Wed, Sep 05, 2007 at 09:41:50PM -0500, Chris Bowman (Home) wrote:
I was recently testing the in kernel nat patch, which is an absolutely
wonderful addition in my opinion. I have however run into one issue, when
for example I do the following :
ipfw nat 10 config ip 2.2.2.2
[snip
is an absolutely
wonderful addition in my opinion. I have however run into one issue, when
for example I do the following :
ipfw nat 10 config ip 2.2.2.2
[snip]
Where did you get the 6.x patch? Did you find a tarball around or
you backported the code from 7.x?
In the first case
Ok, the obvious part that I think I was missing while it was late, was
that these must be keep-alive packets generated by the firewall as the
dynamic rules are about to expire. That being the case however,
shouldn't these keep-alive packets take the same action as the original
rule (skipto
On Saturday 02 December 2006 19:00, James Halstead wrote:
Ok, the obvious part that I think I was missing while it was late,
was that these must be keep-alive packets generated by the firewall as
the dynamic rules are about to expire. That being the case however,
shouldn't these keep-alive
1 - 100 of 116 matches
Mail list logo