Re: ipfw layer2+3 firewalling question

Hi Ronald, thank you for your reply. On Sun, Mar 23, 2025 at 08:21:21PM +0100, Ronald Klop wrote: I assume that in your setup igb0 is the host interface as well as bridge member. That's correct. That makes the setup a bit hard to reason about. IMHO you now have a virtual setup which you wo

Re: ipfw layer2+3 firewalling question

Op 23-03-2025 om 15:07 schreef void: Hi, (originally posted on the forums) My objective is to protect services on a bhyve host, while allowing traffic to the bhyve guests to pass to and from them unprocessed, as these each have pf and their own firewall policies. The host running recent -curr

Re: IPFW statefull firewall ruleset - some sites or applications do not work as expected

D Net Onderwerp: Re: IPFW statefull firewall ruleset - some sites or applications do not work as expected Hi, unfortunately that's not the case, as I have onepass to off, meaning that after every rule, the packet continues to be processed by the next rule (so the NAT does get reached).

Re: IPFW statefull firewall ruleset - some sites or applications do not work as expected

Hi, unfortunately that's not the case, as I have onepass to off, meaning that after every rule, the packet continues to be processed by the next rule (so the NAT does get reached). Op do 14 nov 2024 om 11:17 schreef Ronald Klop : > Op 02-11-2024 om 16:30 schreef Dries Michiels: > > Hello, > > >

Re: IPFW statefull firewall ruleset - some sites or applications do not work as expected

Op 02-11-2024 om 16:30 schreef Dries Michiels: Hello, So I have a very basic ruleset, as described in the FreeBSD handbook, see below. I have "blurred" my open ports as seen in the ruleset below. Igc0 is my WAN port and in the table "trusted_if" are like my LAN if and some bridges. 1 reas

Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

Am Mon, 8 Jan 2024 01:33:53 +0100 (CET) Felix Reichenberger schrieb: > > Hello, > > > > I've got a problem with recent CURRENT, running vnet JAILs. > > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > > 2024 amd64 > > > > Main Host has IPFW configured and is open for

Re: IPFW/IPv6 problem with JAIL: JAIL cannot ping -6 host until host first pings jail (ipv6)

> Hello, > > I've got a problem with recent CURRENT, running vnet JAILs. > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET > 2024 amd64 > > Main Host has IPFW configured and is open for services like OpenLDAP on > UDP/TCP and ICMP > (ipfw is configured via rc.conf in

Re: ipfw firewalling for bhyve host, bypassing bhyve guests

On Sun, Oct 15, 2023 at 10:46:57AM -0700, Paul Vixie wrote: You don't need L2 for this. The firewall pattern when your bare metal host has an address in the vlan you use for guests is: Allow the specific things you want the bare metal host to do; Deny all else involving the bare metal host; A

Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User пишет: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 int

Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW

18.02.2023 18:42, FreeBSD User пишет: On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 cor

Re: IPFW NAT intermittently fails to redirect UDP packets; seeking DTrace scripts or other advice

> Only a quick look ... > > There is no guarantee, that the ports of the UDP packets are not modified by > libalias (NAT is designed to do exactly this modification). So some of the > matches seems to be a bit optimistic, > > > - This system has net.inet.ip.fw.one_pass=0 > > > man ipfw >

Re: IPFW NAT intermittently fails to redirect UDP packets; seeking DTrace scripts or other advice

On Mon, Aug 29, 2022 at 06:36:26PM +, tt78347 wrote: > ipfw -q nat 1 config if $extif unreg_only reset \ > redirect_port udp 192.168.21.4:500 500 \ > redirect_port udp 192.168.21.4:4500 4500 > $add 450 nat 1 udp from any to any 500,4500 in via $extif > $add 451 nat 1 udp from any to any 50

Re: ipfw stateful rules and quick port re-use

Check the values of these sysctl MIBS net.inet.ip.fw.dyn_keep_states net.inet.ip.fw.dyn_keepalive net.inet.ip.fw.dyn_short_lifetime net.inet.ip.fw.dyn_udp_lifetime net.inet.ip.fw.dyn_rst_lifetime net.inet.ip.fw.dyn_fin_lifetime net.inet.ip.fw.dyn_syn_lifetime net.inet.ip.fw.dyn_ack_lifetime

Re: ipfw nat bug

30.11.2020 16:10, Eugene Grosbein wrote: > Hi! > > It seems I'm facing a bug in NAT44 ipfw nat/libalias implementation. > > Suppose we have a LAN 192.168.0.0/24 and two WAN channels with public IP > addresses > and internal server 192.168.0.100 that serves connection to the port 5060, > both T

Re: IPFW In-Kernel NAT vs PF NAT Performance

On Thu, 19 Mar 2020 14:33:34 +0300 Lev Serebryakov wrote: > On 19.03.2020 7:14, Neel Chauhan wrote: > > > However, if you know, where in the code does libalias use only 4096 > > buckets? I want to know incase I want/have to switch back to IPFW. > 4096 is my mistake, it is 4001 and must be pri

Re: IPFW In-Kernel NAT vs PF NAT Performance

On 19.03.2020 7:14, Neel Chauhan wrote: > However, if you know, where in the code does libalias use only 4096 > buckets? I want to know incase I want/have to switch back to IPFW. 4096 is my mistake, it is 4001 and must be prime. It is here: sys/netinet/libalias/alias_local.h:69-70: #define LINK

Re: IPFW In-Kernel NAT vs PF NAT Performance

19.03.2020 18:19, Lev Serebryakov wrote: >> Don't you think that now as ipfw nat builds libalias in kernel context, >> it could scale with maxusers (sys/systm.h) ? >> >> Something like (4001 + (maxusers-32)*8) so it grows with amount of physical >> memory >> and is kept small for low-memory syste

Re: IPFW In-Kernel NAT vs PF NAT Performance

On 19.03.2020 9:42, Eugene Grosbein wrote: >>> I’d expect both ipfw and pf to happily saturate gigabit links with NAT, >>> even on quite modest hardware. >>> Are you sure the NAT code is the bottleneck? >> ipfw nat is very slow, really. There are many reasons, and one of them >> (easy fixable, b

Re: IPFW In-Kernel NAT vs PF NAT Performance

19.03.2020 13:42, Eugene Grosbein wrote: > It's really 4001 that is (and sould be) prime number. If we decide to auto-tune this, here is small table of prime numbers to stick with: 4001 8011 12011 16001 24001 32003 48017 64007 ___ freebsd-net@freebsd

Re: IPFW In-Kernel NAT vs PF NAT Performance

18.03.2020 21:25, Lev Serebryakov wrote: > On 18.03.2020 9:17, Kristof Provost wrote: > >>> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I >>> am dealing with 1000s of concurrent connections but >>> browsing-level-bandwidth at once with Tor. >>> >> I’d expect both ip

Re: IPFW In-Kernel NAT vs PF NAT Performance

Thanks for telling me this. I switched to PF and it performs better. However, if you know, where in the code does libalias use only 4096 buckets? I want to know incase I want/have to switch back to IPFW. -Neel On 2020-03-18 07:25, Lev Serebryakov wrote: On 18.03.2020 9:17, Kristof Provost w

Re: IPFW In-Kernel NAT vs PF NAT Performance

On 18.03.2020 9:17, Kristof Provost wrote: >> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I >> am dealing with 1000s of concurrent connections but browsing-level-bandwidth >> at once with Tor. >> > I’d expect both ipfw and pf to happily saturate gigabit links with NA

Re: IPFW In-Kernel NAT vs PF NAT Performance

> On 18 Mar 2020, at 13:31, Neel Chauhan wrote: > > Hi freebsd-net@ mailing list, > > Right now, my firewall is a HP T730 thin client (with a Dell Broadcom 5720 > PCIe NIC) running FreeBSD 12.1 and IPFW's In-Kernel NAT. My ISP is "Wave G" > in the Seattle area, and I have the Gigabit plan.

Re: IPFW NAT64 changed 11.2 --> 11.3?

Hi all, first, for completeness: > So (3rd line) the SYN/ACK arrives with correct IPv4 addresses then get’s > forwarded with a source address of > > :200:0:50:e689:9765:7085 instead of 64:ff9b::9765:7085 That looks like random garbage due to an uninitialized struct in6_addr. > Then we h

Re: IPFW NAT64 changed 11.2 --> 11.3?

On 26.06.2019 14:23, Patrick M. Hausen wrote: > Hi all, > >> Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov : >> >> On 26.06.2019 13:10, Patrick M. Hausen wrote: >>> tcpdump will take some more time, currently we do not have /dev/bpf in >>> these jails. >> >> So, nat64_direct_output didn't help

Re: IPFW NAT64 changed 11.2 --> 11.3?

Hi all, > Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov : > > On 26.06.2019 13:10, Patrick M. Hausen wrote: >> tcpdump will take some more time, currently we do not have /dev/bpf in these >> jails. > > So, nat64_direct_output didn't help? > Does `ipfw nat64lsn NAT64 list states` shows correc

Re: IPFW NAT64 changed 11.2 --> 11.3?

On 26.06.2019 13:10, Patrick M. Hausen wrote: > tcpdump will take some more time, currently we do not have /dev/bpf in these > jails. So, nat64_direct_output didn't help? Does `ipfw nat64lsn NAT64 list states` shows correct addresses? -- WBR, Andrey V. Elsukov signature.asc Description: Open

Re: IPFW NAT64 changed 11.2 --> 11.3?

> Am 26.06.2019 um 11:47 schrieb Andrey V. Elsukov : > Check the output of the following commands on both translators: > > # sysctl net.inet.ip.fw | grep nat64 > # ipfw nat64lsn all list > # ipfw nat64lsn NAT64 stats Working 11.2 system: root@gate64:~ # sysctl net.inet.ip.fw | grep nat64 net.ine

Re: IPFW NAT64 changed 11.2 --> 11.3?

On 26.06.2019 11:05, Patrick M. Hausen wrote: > Hi all, > > we have a bit of a problem with some new servers that > use NAT64 to access certain services that offer only > legacy IP - like github. > > As far as I found the respective NAT64 gateways (in jails > with VNET) are configured identically

Re: IPFW NAT in VNET jail

On Fri, 22 Feb 2019, Giacomo Olgeni wrote: > 00100 00 nat 1 ip from any to any recv epair0b > 00200 74 4080 nat 1 ip from any to any xmit epair0b > 00300 00 check-state :default > 00400 6 360 allow tcp from any to any out xmit epair0b setup > keep-sta

Re: ipfw on bridge connecting vlans

On 27/10/2018 21:02, Eugene Grosbein wrote: 28.10.2018 0:48, Victor Gamov wrote: On 27/10/2018 19:33, Eugene Grosbein wrote: 27.10.2018 23:26, Victor Gamov wrote: [skip] net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from bridge member, zero disables this pass. net.li

Re: ipfw on bridge connecting vlans

28.10.2018 0:48, Victor Gamov wrote: > On 27/10/2018 19:33, Eugene Grosbein wrote: >> 27.10.2018 23:26, Victor Gamov wrote: >> >> [skip] >> net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from bridge member, zero disables this pass. net.link.bridge.ipfw=1 m

Re: ipfw on bridge connecting vlans

On 27/10/2018 19:33, Eugene Grosbein wrote: 27.10.2018 23:26, Victor Gamov wrote: [skip] net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from bridge member, zero disables this pass. net.link.bridge.ipfw=1 makes frames enter ruleset again as incoming from bridge interface

Re: ipfw on bridge connecting vlans

27.10.2018 23:26, Victor Gamov wrote: [skip] >> net.link.bridge.pfil_member=1 makes frames enter ruleset as incoming from >> bridge member, zero disables this pass. >> >> net.link.bridge.ipfw=1 makes frames enter ruleset again as incoming from >> bridge interface itself >> without distinction o

Re: ipfw on bridge connecting vlans

On 27/10/2018 18:44, Eugene Grosbein wrote: 27.10.2018 22:16, Victor Gamov wrote: Hi All I have some misunderstanding how ipfw work with VLAN and bridge I have following config bridge2 / | \ / | \ /| \ vlan200 vl

Re: ipfw on bridge connecting vlans

27.10.2018 22:16, Victor Gamov wrote: > > Hi All > > I have some misunderstanding how ipfw work with VLAN and bridge > > I have following config > > > bridge2 > > / | \ > / | \ >/| \ > vlan200 vlan300 vlan400 > (igb0)

Re: Ipfw fwd with route(8) RTF_BLACKHOLE and fast forwarding on FreeBSD 11

Thank you Еugen for your reply. You have very clearly explained how to disable fast forwarding via kernel ipsec. From myself I will add. On this object (Server), the priority is in favor of fast forwarding. Filtering ICMP packets I will make ipfw rules.I think that even with the use of ipfw f

Re: Ipfw fwd with route(8) RTF_BLACKHOLE and fast forwarding on FreeBSD 11

At your request Eugen, I fill in the Problem Report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231143 03.09.2018 12:33, Eugene Grosbein пишет: 03.09.2018 14:02, Runer wrote: *Hello Community! A situation has arisen in which ipfw fwd stops working when RTF_BLACKHOLE or RTF_REJECT, RO

Re: Ipfw fwd with route(8) RTF_BLACKHOLE and fast forwarding on FreeBSD 11

> As temporary workaround, you still can disable fast forwarding path: > > - make sure you use GENERIC kernel or your custom kernel has "options > IPSEC_SUPPORT" like GENERIC has; > - load ipsec kernel module by means of /boot/loader.conf or /etc/rc.conf; > - add dummy security policy: > > print

Re: Ipfw fwd with route(8) RTF_BLACKHOLE and fast forwarding on FreeBSD 11

03.09.2018 14:02, Runer wrote: > *Hello Community! > > A situation has arisen in which ipfw fwd stops working when > RTF_BLACKHOLE or RTF_REJECT, ROUTE (8), is enabled on Freebsd 11 release. > ** > > FreeBSD 11.2-RELEASE-p1 route add default 127.0.0.1 -blackhole –iface ipfw > show00100 30 4056 f

Re: Ipfw fwd with route(8) RTF_BLACKHOLE and fast forwarding on FreeBSD 11

03.09.2018 14:02, Runer wrote: > *Hello Community! > > A situation has arisen in which ipfw fwd stops working when > RTF_BLACKHOLE or RTF_REJECT, ROUTE (8), is enabled on Freebsd 11 release. > ** > > FreeBSD 11.2-RELEASE-p1 route add default 127.0.0.1 -blackhole –iface ipfw > show00100 30 4056

Re: ipfw -- selecting locally generated packets

On 5/5/18 1:33 am, Jeff Kletsky wrote: On 5/3/18 6:35 AM, Julian Elischer wrote: On 3/5/18 12:08 am, Michael Sierchio wrote: On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky wrote: "not recv any" doesn't seem to be helpful either $ sudo ipfw add 64000 count ip from any to any out xmit

Re: ipfw -- selecting locally generated packets

On 5/3/18 6:35 AM, Julian Elischer wrote: On 3/5/18 12:08 am, Michael Sierchio wrote: On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky wrote: "not recv any" doesn't seem to be helpful either $ sudo ipfw add 64000 count ip from any to any out xmit any not recv any The loopback inter

Re: ipfw -- selecting locally generated packets

On 3/5/18 12:08 am, Michael Sierchio wrote: On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky wrote: "not recv any" doesn't seem to be helpful either $ sudo ipfw add 64000 count ip from any to any out xmit any not recv any The loopback interface, lo0 ?

Re: ipfw -- selecting locally generated packets

On Mon, Apr 30, 2018 at 10:48 AM, Jeff Kletsky wrote: > > "not recv any" doesn't seem to be helpful either > > $ sudo ipfw add 64000 count ip from any to any out xmit any not recv > any The loopback interface, lo0 ? ___ freebsd-net@freebsd.org mai

Re: ipfw -- selecting locally generated packets

On Tue, May 01, 2018 at 09:04:36PM +0800, Julian Elischer wrote: > On 1/5/18 2:02 am, Eugene Grosbein wrote: > >01.05.2018 0:48, Jeff Kletsky wrote: > > > >> From time to time, I rewrite my firewall rules to take advantages of the > >> ever-improving set of features that ipfw provides. One of the

Re: ipfw -- selecting locally generated packets

On 1/5/18 2:02 am, Eugene Grosbein wrote: 01.05.2018 0:48, Jeff Kletsky wrote: From time to time, I rewrite my firewall rules to take advantages of the ever-improving set of features that ipfw provides. One of the challenges I have faced in the past was selecting packets that are generated o

Re: ipfw -- selecting locally generated packets

01.05.2018 0:48, Jeff Kletsky wrote: > From time to time, I rewrite my firewall rules to take advantages of the > ever-improving set of features that ipfw provides. One of the challenges I > have faced in the past was selecting packets that are generated on the > firewall host itself, as oppose

Re: IPFW: Packet forwarding with bridges and vlans and Vimage? With an IP address.

> On 15 Jun 2016, at 14:04, Dr Josef Karthauser wrote: > > I don’t have IP forwarding switched on and so I’d expect bridged packets to > carry on being bridged irrespective of whether vlan9 has an IP address or not. > > What’s strange is that ingress packets to the bridge are being forwarded ok

Re: ipfw fwd to closed port

On Thu, Jun 09, 2016 at 09:08:33AM -0400, Kristof Provost wrote: > > > On 9 Jun 2016, at 9:06, Slawa Olhovchenkov wrote: > > > On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > > > >> On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > >>> Forwarding by ipfw to closed

Re: ipfw fwd to closed port

On 9 Jun 2016, at 9:06, Slawa Olhovchenkov wrote: > On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > >> On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: >>> Forwarding by ipfw to closed local port generating RST packet with >>> incorrect checksun. Is this know ussuse?

Re: ipfw fwd to closed port

On Thu, Jun 09, 2016 at 03:00:17PM +0200, Kristof Provost wrote: > On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > > Forwarding by ipfw to closed local port generating RST packet with > > incorrect checksun. Is this know ussuse? Need open PR? > > Where did you capture the packet? If

Re: ipfw fwd to closed port

On 2016-06-09 02:02:40 (+0300), Slawa Olhovchenkov wrote: > Forwarding by ipfw to closed local port generating RST packet with > incorrect checksun. Is this know ussuse? Need open PR? Where did you capture the packet? If you've captured the packet on the machine that generated it tcpdump may inde

Re: IPFW: table support for MAC addresses?

For what it is worth, I also would use this Feature. to whitelist a set of MACS On Sun, Jun 5, 2016 at 4:14 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > On Sun, Jun 05, 2016 at 01:41:12PM +0300, Alexander V. Chernikov wrote: > > 05.06.2016, 11:45, "??zkan KIRIK" : > > > I also need this feat

Re: IPFW: table support for MAC addresses?

On Sun, Jun 05, 2016 at 01:41:12PM +0300, Alexander V. Chernikov wrote: > 05.06.2016, 11:45, "??zkan KIRIK" : > > I also need this feature > > Are you fine with exact-match mac addresses? Yes, exact-match is fine for me. > (E.g. new array/hash tabletype with the ability to do exact lookup on the

Re: IPFW: table support for MAC addresses?

On 05.06.2016 12:41, Alexander V. Chernikov wrote: Are you fine with exact-match mac addresses? (E.g. new array/hash tabletype with the ability to do exact lookup on the source/destination mac address, w/o any masks support). Yes, exact-match would totally satisfy my requirements. Regards, Ju

Re: IPFW: table support for MAC addresses?

05.06.2016, 11:45, "Özkan KIRIK" : > I also need this feature Are you fine with exact-match mac addresses? (E.g. new array/hash tabletype with the ability to do exact lookup on the source/destination mac address, w/o any masks support). > > On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <".

Re: IPFW: table support for MAC addresses?

I also need this feature On Fri, Jun 3, 2016 at 4:11 PM, Aleksandr A Babaylov <"."@babolo.ru> wrote: > On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > > is there anyone who wants to use MAC based rules with IPFW? > > I want to build a captive portal that also supports IPv6. MAC addre

Re: IPFW: table support for MAC addresses?

On Thu, Jun 02, 2016 at 02:18:56PM +0200, Julian K. wrote: > is there anyone who wants to use MAC based rules with IPFW? > I want to build a captive portal that also supports IPv6. MAC addresses > in IPFW tables would help a lot. I use MAC in IPFW and want MAC in IPFW tables to simplify rules. __

Re: IPFW: table support for MAC addresses?

Hi, is there anyone who wants to use MAC based rules with IPFW? I want to build a captive portal that also supports IPv6. MAC addresses in IPFW tables would help a lot. Regards, Julian On 31.05.2016 14:56, Julian K. wrote: Hi, I studied the IPFW improvements in FreeBSD 11. Unfortunately I c

IPFW with NAT (breakage with vlanhwtag enabled) Re: IPFW with NAT : Problems with duplicate packets on FreeBSD 10.3-RC3

> On 8 Apr 2016, at 10:03, Dr Josef Karthauser wrote: > >> On 8 Apr 2016, at 06:51, Ian Smith > > wrote: >> >> On Thu, 7 Apr 2016 17:08:38 +0100, Dr Josef Karthauser wrote: >> >>> Looks like the first packet is being retransmitted, which means that >>> the nat is

Re: IPFW with NAT : Problems with duplicate packets on FreeBSD 10.3-RC3

> On 8 Apr 2016, at 06:51, Ian Smith wrote: > > On Thu, 7 Apr 2016 17:08:38 +0100, Dr Josef Karthauser wrote: > > [ AppleMail msgs fail to quote properly in pine, so a partial quote: ] > >> Looks like the first packet is being retransmitted, which means that >> the nat is probably misconfigure

Re: IPFW with NAT : Problems with duplicate packets on FreeBSD 10.3-RC3

On Thu, 7 Apr 2016 17:08:38 +0100, Dr Josef Karthauser wrote: [ AppleMail msgs fail to quote properly in pine, so a partial quote: ] > Looks like the first packet is being retransmitted, which means that > the nat is probably misconfigured and the TCP connection is broken in > some strange wa

Re: IPFW with NAT : Problems with duplicate packets on FreeBSD 10.3-RC3

> On 8 Apr 2016, at 00:11, Dr Josef Karthauser wrote: > >> On 7 Apr 2016, at 17:08, Dr Josef Karthauser > > wrote: >> >> Looks like the first packet is being retransmitted, which means that the nat >> is probably misconfigured and the TCP connection is broken in some

Re: IPFW with NAT : Problems with duplicate packets on FreeBSD 10.3-RC3

> On 7 Apr 2016, at 17:08, Dr Josef Karthauser wrote: > > Looks like the first packet is being retransmitted, which means that the nat > is probably misconfigured and the TCP connection is broken in some strange > way. > > Does anyone have a clue as to where to look? The ipfw rules are simple

Re: ipfw NAT /etc/rc.firewall question

On 01/24/16 23:25, Ian Smith wrote: On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote: > Hi, > > I am making myself learn better how ipfw works. I am curious about > the optimal location of the NAT rule definition code. My immediate > application is a generic NATing gatewa

Re: ipfw NAT /etc/rc.firewall question

On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote: > Hi, > > I am making myself learn better how ipfw works. I am curious about > the optimal location of the NAT rule definition code. My immediate > application is a generic NATing gateway with an outside iface armored > up and an

Re: ipfw NAT, igb and hardware checksums

13.01.2016, 22:56, "Karim Fodil-Lemelin" : > 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=0x8

Re: ipfw NAT, igb and hardware checksums

This looks mostly sensible. hm! -a On 13 January 2016 at 11:55, Karim Fodil-Lemelin 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(). Here is the > story: > > I am using the following

Re: IPFW blocked my IPv6 NTP traffic

On 2/12/2015 12:27 AM, el...@sentor.se wrote: On Tue, 1 Dec 2015, Mark Felder wrote: On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: Hi, Mark. I'm hoping someone can explain what happened here and this isn't a bug, but if it is a bug I'll gladly open a PR. I noticed in my ipfw logs th

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 12:08, Gary Palmer wrote: > > Have you looked at the ipfw state tables to see if a state is recorded? > > ipfw -d list > > I think > Yes, and I can see the state especially for IPv6. I think I have solved this mystery. There was a problem, and I solved it, but then w

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 01, 2015 at 12:00:47PM -0600, Mark Felder wrote: > > > On Tue, Dec 1, 2015, at 09:16, wishmaster wrote: > > > > --- Original message --- > > From: "Mark Felder" > > Date: 1 December 2015, 17:05:35 > > > > > > > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: >

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 09:16, wishmaster wrote: > > --- Original message --- > From: "Mark Felder" > Date: 1 December 2015, 17:05:35 > > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > > > > > Hi, Mark. > > > > > > > > > > I'm hoping someone can explain what happe

Re: IPFW blocked my IPv6 NTP traffic

On Tue, 1 Dec 2015, Mark Felder wrote: On Tue, Dec 1, 2015, at 10:50, el...@sentor.se wrote: Not that this helps this thread to move on, but just to clarify: In this case, the NAT that would introduce the randomized src port would be *your* NAT, not a NAT at pool.ntp.org. Deny UDP [2604:a

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 10:50, el...@sentor.se wrote: > > Not that this helps this thread to move on, but just to clarify: > > In this case, the NAT that would introduce the randomized src port would > be *your* NAT, not a NAT at pool.ntp.org. > > > Deny UDP [2604:a880:800:10::bc:c004]:123 [

Re: IPFW blocked my IPv6 NTP traffic

On Tue, 1 Dec 2015, Mark Felder wrote: On Tue, Dec 1, 2015, at 09:53, el...@sentor.se wrote: On Tue, 1 Dec 2015, Matthew Seaman wrote: On 2015/12/01 15:05, Mark Felder wrote: Notice how almost all of them are port 123 on both sides, but a few of them are not. Why? The RFC says that NTP is

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 10:27, el...@sentor.se wrote: > On Tue, 1 Dec 2015, Mark Felder wrote: > > > > > > > On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > >> > >> Hi, Mark. > >> > >> > >>> I'm hoping someone can explain what happened here and this isn't a bug, > >>> but if it is a bug I'll

Re: IPFW blocked my IPv6 NTP traffic

On Tue, 1 Dec 2015, Mark Felder wrote: On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: Hi, Mark. I'm hoping someone can explain what happened here and this isn't a bug, but if it is a bug I'll gladly open a PR. I noticed in my ipfw logs that I was getting a log of "DENY" entries for an

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 09:53, el...@sentor.se wrote: > > On Tue, 1 Dec 2015, Matthew Seaman wrote: > > > On 2015/12/01 15:05, Mark Felder wrote: > >> Notice how almost all of them are port 123 on both sides, but a few of > >> them are not. Why? The RFC says that NTP is supposed to be using por

Re: IPFW blocked my IPv6 NTP traffic

On Tue, 1 Dec 2015, Matthew Seaman wrote: On 2015/12/01 15:05, Mark Felder wrote: Notice how almost all of them are port 123 on both sides, but a few of them are not. Why? The RFC says that NTP is supposed to be using port 123 as both the source and destination port, but I clearly have somethi

Re: IPFW blocked my IPv6 NTP traffic

On 2015/12/01 15:05, Mark Felder wrote: > Notice how almost all of them are port 123 on both sides, but a few of > them are not. Why? The RFC says that NTP is supposed to be using port > 123 as both the source and destination port, but I clearly have > something happening on port 16205. Is somethin

Re: IPFW blocked my IPv6 NTP traffic

On Tue, Dec 1, 2015, at 02:02, wishmaster wrote: > > Hi, Mark. > > > > I'm hoping someone can explain what happened here and this isn't a bug, > > but if it is a bug I'll gladly open a PR. > > > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > > an NTP server > >

Re: IPFW blocked my IPv6 NTP traffic

Hi, Mark. > I'm hoping someone can explain what happened here and this isn't a bug, > but if it is a bug I'll gladly open a PR. > > I noticed in my ipfw logs that I was getting a log of "DENY" entries for > an NTP server > > Nov 30 13:35:16 gw kernel: ipfw: 4540 Deny UDP > [2604:a880:800:10::

Re: IPFW blocked my IPv6 NTP traffic

Hi, Mark-- On Nov 30, 2015, at 1:58 PM, Mark Felder wrote: > [ ... ] > I noticed my outbound IPv6 didn't have $ks for udp, so I added it. > However, that had no effect. The solution was to add an incoming rule: > > $cmd 03755 allow udp from any to any src-port 123 in via $pif6 $ks > > This seem

Re: IPFW divert and suricata

On 7/1/15 10:31 PM, Luigi Rizzo wrote: On Wed, Jul 1, 2015 at 3:15 PM, Oliver Humpage wrote: Hello, I hope this is a good list to post this on, I have a feeling the solution is somewhere obscure in the networking layer. I've set up an IPS system, using: * FreeBSD 10.1 (guest OS, plenty of R

Re: IPFW divert and suricata

On 1 Jul 2015, at 15:31, Luigi Rizzo wrote: > For the latter two, you might be better off using netmap > on vmxnet3 (in emulated mode, also disabling offloads), > and if i remember well a couple of years ago there were > efforts to use ​suricata on top of netmap. > Worst case, you can just use t

Re: IPFW divert and suricata

On Wed, Jul 1, 2015 at 3:15 PM, Oliver Humpage wrote: > > Hello, > > I hope this is a good list to post this on, I have a feeling the solution > is somewhere obscure in the networking layer. > > I've set up an IPS system, using: > > * FreeBSD 10.1 (guest OS, plenty of RAM/CPU) > * ESXi 5.5 (host

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30.01.2015 12:22, wishmaster wrote: > At first, i think you should move keep-state from skipto to > explicit allow rule. Yep! I like it TOO! > For my case with 4 ISP link I use something like this example, but > more complex, though. Could you

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

On Fri, 30 Jan 2015 12:05:07 +0300, Lev Serebryakov wrote: > On 30.01.2015 05:33, Julian Elischer wrote: > > >> 12700 skipto 12900 ip from any to any keep-state 12800 deny ip > >> from any to any 12900 nat 1 ip from any to any out 12999 allow ip > >> from any to any > >> > >> And rules for

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

Hi, below my experience. --- Original message --- From: "Lev Serebryakov" Date: 30 January 2015, 02:37:54 > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > I have problems to understand how combination of nat and stateful > ruleset for ipfw should work. There is no good gui

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30.01.2015 05:33, Julian Elischer wrote: >> 12700 skipto 12900 ip from any to any keep-state 12800 deny ip >> from any to any 12900 nat 1 ip from any to any out 12999 allow ip >> from any to any >> >> And rules for inbound ones are: >> >> 11000

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

On 1/30/15 8:37 AM, Lev Serebryakov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have problems to understand how combination of nat and stateful ruleset for ipfw should work. There is no good guides, and most guides uses old "divert" which is different from in-kernel nat, as far a

Re: ipfw, nat and stateful firewall: why "keep-state" on "skipto" works at all and how do this properly?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 30.01.2015 03:37, Lev Serebryakov wrote: > Is here better way to have nat and stateful ruleset? Actions like "create-dyn-allow" and "create-dyn-deny" will be very nice, BTW :) But looks like it is hard to add, as now dynamic rules are "replaced

Re: ipfw fwd duplicating packets in 9.3-RELEASE

For documentation: I do not know why or how, but after trying to reproduce the same strange behaviour, it did not happen. This was after restarting all the test environment. Weird. Sorry for take your time with this strange mess. Regards, Raimundo Santos On 29 October 2014 14:30, Raimundo Sant

Re: ipfw fwd duplicating packets in 9.3-RELEASE

On 29 October 2014 12:53, bycn82 wrote: > > Hi, > I cannot help to point out when the ICMP packet was duplicated and transfer > via 2 different links, If it happens in my machine, I will call this feature > "multi-homing". That is a bit off topic, but how and undesired behaviour could be a featu

RE: ipfw fwd duplicating packets in 9.3-RELEASE

Hi, I cannot help to point out when the ICMP packet was duplicated and transfer via 2 different links, If it happens in my machine, I will call this feature "multi-homing". But what I want to say is the firewall rule fwd 192.168.0.2 proto icmp src-ip 192.168.4.2 out xmit em1 You can remove the "ou

Re: ipfw command freezes system

On 10/23/14, 7:41 AM, javocado wrote: I'm seeing an occasional, recurring problem on my 8.3-RELEASE amd64 systems where when I enter an ipfw rule, the system becomes locked up. For example, when entering a command like this: ipfw add 1 allow ip from x.x.x.x to me or other times with a command

Re: ipfw named objejcts, table values and syntax change

19.08.2014 21:36, Alexander V. Chernikov пишет: On 19.08.2014 20:06, Dmitry Selivanov wrote: 19.08.2014 17:50, Alexander V. Chernikov пишет: On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.0

Re: ipfw named objejcts, table values and syntax change

On 19.08.2014 20:06, Dmitry Selivanov wrote: 19.08.2014 17:50, Alexander V. Chernikov пишет: On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014

Re: ipfw named objejcts, table values and syntax change

19.08.2014 17:50, Alexander V. Chernikov пишет: On 15.08.2014 19:20, Alexander V. Chernikov wrote: On 15.08.2014 18:19, Dmitry Selivanov wrote: 15.08.2014 17:25, Alexander V. Chernikov пишет: On 08.08.2014 16:11, Dmitry Selivanov wrote: 04.08.2014 23:51, Alexander V. Chernikov пишет: On 04.0

  1   2   3   4   5   6   >