Issues with TCP Timestamps allocation
Hi team,
Recently we had an upgrade to 12 Stable. Immediately after, we have started
seeing some strange connection establishment timeouts to some fixed number
of external (world) hosts. The issue was persistent and easy to reproduce.
Thanks to a patience and dedication of our system engineer we have tracked
this issue down to a specific commit:
https://svnweb.freebsd.org/base?view=revision&revision=338053
This patch was also back-ported into 11 Stable:
https://svnweb.freebsd.org/base?view=revision&revision=348435
Among other things this patch changes the timestamp allocation strategy,
by introducing a deterministic randomness via a hash function that takes
into account a random key as well as source address, source port, dest
address and dest port. As the result, timestamp offsets of different
tuples (SA,SP,DA,DP) will be wildly different and will jump from small
to large numbers and back, as long as something in the tuple changes.
After performing various tests of hosts that produce the above mentioned
issue we came to conclusion that there are some interesting implementations
that drop SYN packets with timestamps smaller than the largest timestamp
value from streams of all recent or current connections from a specific
address. This looks as some kind of SYN flood protection.
To ensure that each external host is not going to see a wild jumps of
timestamp values I propose a patch that removes ports from the equation
all together, when calculating the timestamp offset:
Index: sys/netinet/tcp_subr.c
===
--- sys/netinet/tcp_subr.c (revision 348435)
+++ sys/netinet/tcp_subr.c (working copy)
@@ -2224,7 +2224,22 @@
uint32_t
tcp_new_ts_offset(struct in_conninfo *inc)
{
- return (tcp_keyed_hash(inc, V_ts_offset_secret));
+/*
+ * Some implementations show a strange behaviour when a wildly random
+ * timestamps allocated for different streams. It seems that only the
+ * SYN packets are affected. Observed implementations drop SYN packets
+ * with timestamps smaller than the largest timestamp value of all
+ * recent or current connections from specific a address. To mitigate
+ * this we are going to ensure that each host will always observe
+ * timestamps as increasing no matter the stream: by dropping ports
+ * from the equation.
+ */
+struct in_conninfo inc_copy = *inc;
+
+inc_copy.inc_fport = 0;
+inc_copy.inc_lport = 0;
+
+ return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
}
/*
In any case, the solution of the uptime leak, implemented in rev338053 is
not going to suffer, because a supposed attacker is currently able to use
any fixed values of SP and DP, albeit not 0, anyway, to remove them out
of the equation.
There is the list of example hosts that we were able to reproduce the
issue with:
curl -v http://88.99.60.171:80
curl -v http://163.172.71.252:80
curl -v http://5.9.242.150:80
curl -v https://185.134.205.105:443
curl -v https://136.243.1.231:443
curl -v https://144.76.196.4:443
curl -v http://94.127.191.194:80
To reproduce, call curl repeatedly with a same URL some number of times.
You are going to see some of the requests stuck in
`*Trying XXX.XXX.XXX.XXX...`
For some reason, the easiest way to reproduce the issue is with nc:
$ echo "foo" | nc -v 88.99.60.171 80
Only a few such calls are required until one of them is stuck on connect():
issuing SYN packets with an exponential backoff.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network?
On 06.07.2019 11:01, Yuri wrote: > My network interface looks like this: > $fw nat 1 config redirect_addr 192.168.100.2 192.168.1.2 redirect_addr > 192.168.1.2 192.168.100.2 if sk0 unreg_only reset > > $fw add 1001 nat 1 tcp from 192.168.100.2/32 to any via sk0 keep-state > > $fw add 1002 check-state > > > The rule 1001 has keep-state, therefore it should process both outgoing > tcp and incoming response packets. But the outbound packets are NATted, > but the inbound ones are not. > > What is wrong, and how to fix this script? 'keep-state' creates state for TCP connection that is not yet translated, thus it won't handle the reply packet, that has translated address/port. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Issues with TCP Timestamps allocation
> On 8. Jul 2019, at 12:37, Paul wrote:
>
> Hi team,
>
> Recently we had an upgrade to 12 Stable. Immediately after, we have started
> seeing some strange connection establishment timeouts to some fixed number
> of external (world) hosts. The issue was persistent and easy to reproduce.
> Thanks to a patience and dedication of our system engineer we have tracked
> this issue down to a specific commit:
>
> https://svnweb.freebsd.org/base?view=revision&revision=338053
>
> This patch was also back-ported into 11 Stable:
>
> https://svnweb.freebsd.org/base?view=revision&revision=348435
>
> Among other things this patch changes the timestamp allocation strategy,
> by introducing a deterministic randomness via a hash function that takes
> into account a random key as well as source address, source port, dest
> address and dest port. As the result, timestamp offsets of different
> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> to large numbers and back, as long as something in the tuple changes.
Hi Paul,
this is correct.
Please note that the same happens with the old method, if two hosts with
different uptimes are bind a consumer grade NAT.
>
> After performing various tests of hosts that produce the above mentioned
> issue we came to conclusion that there are some interesting implementations
> that drop SYN packets with timestamps smaller than the largest timestamp
> value from streams of all recent or current connections from a specific
> address. This looks as some kind of SYN flood protection.
This also breaks multiple hosts with different uptimes behind a consumer
level NAT talking to such a server.
>
> To ensure that each external host is not going to see a wild jumps of
> timestamp values I propose a patch that removes ports from the equation
> all together, when calculating the timestamp offset:
>
> Index: sys/netinet/tcp_subr.c
> ===
> --- sys/netinet/tcp_subr.c(revision 348435)
> +++ sys/netinet/tcp_subr.c(working copy)
> @@ -2224,7 +2224,22 @@
> uint32_t
> tcp_new_ts_offset(struct in_conninfo *inc)
> {
> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> +/*
> + * Some implementations show a strange behaviour when a wildly
> random
> + * timestamps allocated for different streams. It seems that only the
> + * SYN packets are affected. Observed implementations drop SYN
> packets
> + * with timestamps smaller than the largest timestamp value of all
> + * recent or current connections from specific a address. To
> mitigate
> + * this we are going to ensure that each host will always observe
> + * timestamps as increasing no matter the stream: by dropping ports
> + * from the equation.
> + */
> +struct in_conninfo inc_copy = *inc;
> +
> +inc_copy.inc_fport = 0;
> +inc_copy.inc_lport = 0;
> +
> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
> }
>
> /*
>
> In any case, the solution of the uptime leak, implemented in rev338053 is
> not going to suffer, because a supposed attacker is currently able to use
> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> of the equation.
Can you describe how a peer can compute the uptime from two observed timestamps?
I don't see how you can do that...
>
> There is the list of example hosts that we were able to reproduce the
> issue with:
>
> curl -v http://88.99.60.171:80
> curl -v http://163.172.71.252:80
> curl -v http://5.9.242.150:80
> curl -v https://185.134.205.105:443
> curl -v https://136.243.1.231:443
> curl -v https://144.76.196.4:443
> curl -v http://94.127.191.194:80
>
> To reproduce, call curl repeatedly with a same URL some number of times.
> You are going to see some of the requests stuck in
> `*Trying XXX.XXX.XXX.XXX...`
>
> For some reason, the easiest way to reproduce the issue is with nc:
>
> $ echo "foo" | nc -v 88.99.60.171 80
>
> Only a few such calls are required until one of them is stuck on connect():
> issuing SYN packets with an exponential backoff.
Thanks for providing an end-point to test with. I'll take a look.
Just to be clear: You are running a FreeBSD client against one of the above
servers and experience the problem with the new timestamp computations.
You are not running arbitrary clients against a FreeBSD server...
Best regards
Michael
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re[2]: Issues with TCP Timestamps allocation
Hi Michael,
8 July 2019, 15:53:15, by "Michael Tuexen" :
> > On 8. Jul 2019, at 12:37, Paul wrote:
> >
> > Hi team,
> >
> > Recently we had an upgrade to 12 Stable. Immediately after, we have started
> > seeing some strange connection establishment timeouts to some fixed number
> > of external (world) hosts. The issue was persistent and easy to reproduce.
> > Thanks to a patience and dedication of our system engineer we have tracked
> > this issue down to a specific commit:
> >
> > https://svnweb.freebsd.org/base?view=revision&revision=338053
> >
> > This patch was also back-ported into 11 Stable:
> >
> > https://svnweb.freebsd.org/base?view=revision&revision=348435
> >
> > Among other things this patch changes the timestamp allocation strategy,
> > by introducing a deterministic randomness via a hash function that takes
> > into account a random key as well as source address, source port, dest
> > address and dest port. As the result, timestamp offsets of different
> > tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> > to large numbers and back, as long as something in the tuple changes.
> Hi Paul,
>
> this is correct.
>
> Please note that the same happens with the old method, if two hosts with
> different uptimes are bind a consumer grade NAT.
If NAT does not replace timestamps then yes, it should be the case.
> >
> > After performing various tests of hosts that produce the above mentioned
> > issue we came to conclusion that there are some interesting implementations
> > that drop SYN packets with timestamps smaller than the largest timestamp
> > value from streams of all recent or current connections from a specific
> > address. This looks as some kind of SYN flood protection.
> This also breaks multiple hosts with different uptimes behind a consumer
> level NAT talking to such a server.
> >
> > To ensure that each external host is not going to see a wild jumps of
> > timestamp values I propose a patch that removes ports from the equation
> > all together, when calculating the timestamp offset:
> >
> > Index: sys/netinet/tcp_subr.c
> > ===
> > --- sys/netinet/tcp_subr.c (revision 348435)
> > +++ sys/netinet/tcp_subr.c (working copy)
> > @@ -2224,7 +2224,22 @@
> > uint32_t
> > tcp_new_ts_offset(struct in_conninfo *inc)
> > {
> > - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> > +/*
> > + * Some implementations show a strange behaviour when a wildly
> > random
> > + * timestamps allocated for different streams. It seems that only
> > the
> > + * SYN packets are affected. Observed implementations drop SYN
> > packets
> > + * with timestamps smaller than the largest timestamp value of all
> > + * recent or current connections from specific a address. To
> > mitigate
> > + * this we are going to ensure that each host will always observe
> > + * timestamps as increasing no matter the stream: by dropping ports
> > + * from the equation.
> > + */
> > +struct in_conninfo inc_copy = *inc;
> > +
> > +inc_copy.inc_fport = 0;
> > +inc_copy.inc_lport = 0;
> > +
> > + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
> > }
> >
> > /*
> >
> > In any case, the solution of the uptime leak, implemented in rev338053 is
> > not going to suffer, because a supposed attacker is currently able to use
> > any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> > of the equation.
> Can you describe how a peer can compute the uptime from two observed
> timestamps?
> I don't see how you can do that...
Supposed attacker could run a script that continuously monitors timestamps,
for example via a periodic TCP connection from a fixed local port (eg 12345)
and a fixed local address to the fixed victim's address and port (eg 80).
Whenever large discrepancy is observed, attacker can assume that reboot has
happened (due to V_ts_offset_secret re-generation), hence the received
timestamp is considered an approximate point of reboot from which the uptime
can be calculated, until the next reboot and so on.
> >
> > There is the list of example hosts that we were able to reproduce the
> > issue with:
> >
> > curl -v http://88.99.60.171:80
> > curl -v http://163.172.71.252:80
> > curl -v http://5.9.242.150:80
> > curl -v https://185.134.205.105:443
> > curl -v https://136.243.1.231:443
> > curl -v https://144.76.196.4:443
> > curl -v http://94.127.191.194:80
> >
> > To reproduce, call curl repeatedly with a same URL some number of times.
> > You are going to see some of the requests stuck in
> > `*Trying XXX.XXX.XXX.XXX...`
> >
> > For some reason, the easiest way to reproduce the issue is with nc:
> >
> > $ echo "foo" | nc -v 88.99.60.171 80
> >
> > Only a few such calls are required until one of them is stuck on connect():
> > issuing SYN packets with an e
Re: Issues with TCP Timestamps allocation
> On 8. Jul 2019, at 15:24, Paul wrote:
>
> Hi Michael,
>
> 8 July 2019, 15:53:15, by "Michael Tuexen" :
>
>>> On 8. Jul 2019, at 12:37, Paul wrote:
>>>
>>> Hi team,
>>>
>>> Recently we had an upgrade to 12 Stable. Immediately after, we have started
>>> seeing some strange connection establishment timeouts to some fixed number
>>> of external (world) hosts. The issue was persistent and easy to reproduce.
>>> Thanks to a patience and dedication of our system engineer we have tracked
>>> this issue down to a specific commit:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=338053
>>>
>>> This patch was also back-ported into 11 Stable:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=348435
>>>
>>> Among other things this patch changes the timestamp allocation strategy,
>>> by introducing a deterministic randomness via a hash function that takes
>>> into account a random key as well as source address, source port, dest
>>> address and dest port. As the result, timestamp offsets of different
>>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
>>> to large numbers and back, as long as something in the tuple changes.
>> Hi Paul,
>>
>> this is correct.
>>
>> Please note that the same happens with the old method, if two hosts with
>> different uptimes are bind a consumer grade NAT.
>
> If NAT does not replace timestamps then yes, it should be the case.
>
>>>
>>> After performing various tests of hosts that produce the above mentioned
>>> issue we came to conclusion that there are some interesting implementations
>>> that drop SYN packets with timestamps smaller than the largest timestamp
>>> value from streams of all recent or current connections from a specific
>>> address. This looks as some kind of SYN flood protection.
>> This also breaks multiple hosts with different uptimes behind a consumer
>> level NAT talking to such a server.
>>>
>>> To ensure that each external host is not going to see a wild jumps of
>>> timestamp values I propose a patch that removes ports from the equation
>>> all together, when calculating the timestamp offset:
>>>
>>> Index: sys/netinet/tcp_subr.c
>>> ===
>>> --- sys/netinet/tcp_subr.c (revision 348435)
>>> +++ sys/netinet/tcp_subr.c (working copy)
>>> @@ -2224,7 +2224,22 @@
>>> uint32_t
>>> tcp_new_ts_offset(struct in_conninfo *inc)
>>> {
>>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
>>> +/*
>>> + * Some implementations show a strange behaviour when a wildly
>>> random
>>> + * timestamps allocated for different streams. It seems that only
>>> the
>>> + * SYN packets are affected. Observed implementations drop SYN
>>> packets
>>> + * with timestamps smaller than the largest timestamp value of all
>>> + * recent or current connections from specific a address. To
>>> mitigate
>>> + * this we are going to ensure that each host will always observe
>>> + * timestamps as increasing no matter the stream: by dropping ports
>>> + * from the equation.
>>> + */
>>> +struct in_conninfo inc_copy = *inc;
>>> +
>>> +inc_copy.inc_fport = 0;
>>> +inc_copy.inc_lport = 0;
>>> +
>>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
>>> }
>>>
>>> /*
>>>
>>> In any case, the solution of the uptime leak, implemented in rev338053 is
>>> not going to suffer, because a supposed attacker is currently able to use
>>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
>>> of the equation.
>> Can you describe how a peer can compute the uptime from two observed
>> timestamps?
>> I don't see how you can do that...
>
> Supposed attacker could run a script that continuously monitors timestamps,
> for example via a periodic TCP connection from a fixed local port (eg 12345)
> and a fixed local address to the fixed victim's address and port (eg 80).
> Whenever large discrepancy is observed, attacker can assume that reboot has
> happened (due to V_ts_offset_secret re-generation), hence the received
> timestamp is considered an approximate point of reboot from which the uptime
> can be calculated, until the next reboot and so on.
Ahh, I see. The patch we are talking about is not intended to protect against
continuous monitoring, which is something you can always do. You could even
watch for service availability and detect reboots. A change of the local key
would also look similar to a reboot without a temporary loss of connectivity.
Thanks for the clarification.
>
>>>
>>> There is the list of example hosts that we were able to reproduce the
>>> issue with:
>>>
>>> curl -v http://88.99.60.171:80
>>> curl -v http://163.172.71.252:80
>>> curl -v http://5.9.242.150:80
>>> curl -v https://185.134.205.105:443
>>> curl -v https://136.243.1.231:443
>>> curl -v https://144.76.196.4:443
>>> curl -v http://94.127.191.19
Re[2]: Issues with TCP Timestamps allocation
8 July 2019, 17:12:21, by "Michael Tuexen" :
> > On 8. Jul 2019, at 15:24, Paul wrote:
> >
> > Hi Michael,
> >
> > 8 July 2019, 15:53:15, by "Michael Tuexen" :
> >
> >>> On 8. Jul 2019, at 12:37, Paul wrote:
> >>>
> >>> Hi team,
> >>>
> >>> Recently we had an upgrade to 12 Stable. Immediately after, we have
> >>> started
> >>> seeing some strange connection establishment timeouts to some fixed number
> >>> of external (world) hosts. The issue was persistent and easy to reproduce.
> >>> Thanks to a patience and dedication of our system engineer we have
> >>> tracked
> >>> this issue down to a specific commit:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=338053
> >>>
> >>> This patch was also back-ported into 11 Stable:
> >>>
> >>> https://svnweb.freebsd.org/base?view=revision&revision=348435
> >>>
> >>> Among other things this patch changes the timestamp allocation strategy,
> >>> by introducing a deterministic randomness via a hash function that takes
> >>> into account a random key as well as source address, source port, dest
> >>> address and dest port. As the result, timestamp offsets of different
> >>> tuples (SA,SP,DA,DP) will be wildly different and will jump from small
> >>> to large numbers and back, as long as something in the tuple changes.
> >> Hi Paul,
> >>
> >> this is correct.
> >>
> >> Please note that the same happens with the old method, if two hosts with
> >> different uptimes are bind a consumer grade NAT.
> >
> > If NAT does not replace timestamps then yes, it should be the case.
> >
> >>>
> >>> After performing various tests of hosts that produce the above mentioned
> >>> issue we came to conclusion that there are some interesting
> >>> implementations
> >>> that drop SYN packets with timestamps smaller than the largest timestamp
> >>> value from streams of all recent or current connections from a specific
> >>> address. This looks as some kind of SYN flood protection.
> >> This also breaks multiple hosts with different uptimes behind a consumer
> >> level NAT talking to such a server.
> >>>
> >>> To ensure that each external host is not going to see a wild jumps of
> >>> timestamp values I propose a patch that removes ports from the equation
> >>> all together, when calculating the timestamp offset:
> >>>
> >>> Index: sys/netinet/tcp_subr.c
> >>> ===
> >>> --- sys/netinet/tcp_subr.c(revision 348435)
> >>> +++ sys/netinet/tcp_subr.c(working copy)
> >>> @@ -2224,7 +2224,22 @@
> >>> uint32_t
> >>> tcp_new_ts_offset(struct in_conninfo *inc)
> >>> {
> >>> - return (tcp_keyed_hash(inc, V_ts_offset_secret));
> >>> +/*
> >>> + * Some implementations show a strange behaviour when a wildly
> >>> random
> >>> + * timestamps allocated for different streams. It seems that
> >>> only the
> >>> + * SYN packets are affected. Observed implementations drop SYN
> >>> packets
> >>> + * with timestamps smaller than the largest timestamp value of
> >>> all
> >>> + * recent or current connections from specific a address. To
> >>> mitigate
> >>> + * this we are going to ensure that each host will always
> >>> observe
> >>> + * timestamps as increasing no matter the stream: by dropping
> >>> ports
> >>> + * from the equation.
> >>> + */
> >>> +struct in_conninfo inc_copy = *inc;
> >>> +
> >>> +inc_copy.inc_fport = 0;
> >>> +inc_copy.inc_lport = 0;
> >>> +
> >>> + return (tcp_keyed_hash(&inc_copy, V_ts_offset_secret));
> >>> }
> >>>
> >>> /*
> >>>
> >>> In any case, the solution of the uptime leak, implemented in rev338053 is
> >>> not going to suffer, because a supposed attacker is currently able to use
> >>> any fixed values of SP and DP, albeit not 0, anyway, to remove them out
> >>> of the equation.
> >> Can you describe how a peer can compute the uptime from two observed
> >> timestamps?
> >> I don't see how you can do that...
> >
> > Supposed attacker could run a script that continuously monitors timestamps,
> > for example via a periodic TCP connection from a fixed local port (eg
> > 12345)
> > and a fixed local address to the fixed victim's address and port (eg 80).
> > Whenever large discrepancy is observed, attacker can assume that reboot has
> > happened (due to V_ts_offset_secret re-generation), hence the received
> > timestamp is considered an approximate point of reboot from which the uptime
> > can be calculated, until the next reboot and so on.
> Ahh, I see. The patch we are talking about is not intended to protect against
> continuous monitoring, which is something you can always do. You could even
> watch for service availability and detect reboots. A change of the local key
> would also look similar to a reboot without a temporary loss of connectivity.
>
> Thanks for the clarification.
> >
> >>>
> >>> There is the list of exampl
Bridge Not Forwarding ARP
I have a server running FreeBSD 11.2 that I am wanting to use as a bridged firewall. I have it set up and it mostly works. The problem is that ARP replies are not being forwarded from the outside interface to the inside interface. It appears to be working in the other direction. I see the ARP request go out on the outside interface and the reply arrives back at the outside interface. The ARP reply is never getting to the bridge or to the inside interface. The firewall server and the device behind it are in ESX. I think I've worked all the ESX issues out. When I manually add an ARP entry everything works. I've done this before with a physical server running FreeBSD 8.4 and it works as expected. The differences are physical vs virtual, and 8.4 vs 11.2. I'm at a loss as to why it is not working. I've searched the web and found noting. If anyone could offer suggestions on how to fix this or begin to debug it I would greatly appreciate it. Thanks, Dan ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
What's your firewall ruleset look like? (show, don't tell) What does sysctl report on the interfaces and on arp? On Mon, Jul 8, 2019 at 9:15 AM Dan Lists wrote: > I have a server running FreeBSD 11.2 that I am wanting to use as a bridged > firewall. I have it set up and it mostly works. The problem is that ARP > replies are not being forwarded from the outside interface to the inside > interface. It appears to be working in the other direction. I see the > ARP request go out on the outside interface and the reply arrives back at > the outside interface. The ARP reply is never getting to the bridge or to > the inside interface. > > The firewall server and the device behind it are in ESX. I think I've > worked all the ESX issues out. When I manually add an ARP entry everything > works. I've done this before with a physical server running FreeBSD 8.4 > and it works as expected. The differences are physical vs virtual, and > 8.4 vs 11.2. > > I'm at a loss as to why it is not working. I've searched the web and > found noting. If anyone could offer suggestions on how to fix this or > begin to debug it I would greatly appreciate it. > > Thanks, > > Dan > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > -- "Well," Brahmā said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mahābhārata ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: How to set up ipfw(8) NAT between an alias and the main IP address, when the alias is in another network?
NAT is already maintaining state – it is possible to combine stateful rules
and NAT, but don't. ;-)
Are you really proposing to NAT twice, or is 192.168.1.2 a phony address
for the purposes of discussion here?
In any case, consider something like the following:
#!/bin/sh
fw="/sbin/ipfw -q"
sysctl net.inet.ip.fw.one_pass=0
IP_JAIL="192.168.100.2"
IP_EXIF="192.168.1.2"
OIF="sk0"
# If 192.168.1.2 is really your interface address, you'll be nat'ing twice
# on the way to the internet, which is ugly. You don't need the *unreg_only*
# directive if you only have RFC1918 addresses anyway. You should clarify
# if this is the case. *reset* kills all active nat sessions if you run this
# script again.
$fw flush
$fw nat 1 config \
redirect_addr ${IP_EXIF} ${IP_JAIL} \
redirect_addr ${IP_JAIL} ${IP_EXIF} \
if ${OIF} unreg_only reset
# separate in and out as a matter of habit - don't mention protocol in nat
# statement, do this in subsequent rules
$fw add 01000 nat 1 ip from any to any in recv ${OIF}
# check-state isn't needed, really, since it gets performed at the next
# rule that mentions state
#$#$#$#$# $fw add 01500 check-state
# these will match traffic to/from external IP and not jail
$fw add 02000 allow tcp from ${IP_EXIF} to any out setup keep-state
$fw add 02010 allow udp from ${IP_EXIF} to any out keep-state
$fw add 02020 allow icmp from ${IP_EXIF} to any out keep-state
# Why is this safe? because it will only match NAT return packets.
# It only permits traffic to your jail in this case. Also, for TCP to
# function properly, to need to accept ICMP error messages, esp. need-frag
$fw add 02000 allow ip from any to ${IP_JAIL}
# outbound packets pass through nat
$fw add 03000 nat 1 ip from any to any out xmit ${OIF}
# if your default rule (65535) is DENY, you need something like this. This
will
# match only NAT'd traffic
$fw add 5 allow ip from any to any out xmit ${OIF}
On Sat, Jul 6, 2019 at 1:03 AM Yuri wrote:
> My network interface looks like this:
>
> sk0: flags=8843 metric 0 mtu 1500
> options=80009
> ether 01:3c:47:8a:17:12
> inet 192.168.1.2 netmask 0xff00 broadcast 192.168.1.255
> inet 192.168.100.2 netmask 0x broadcast 192.168.100.2
> media: Ethernet autoselect (100baseTX )
> status: active
> nd6 options=29
>
> The second IP address is an alias that is used for jail.
>
> I would like to set up NAT so that this jail would access the internet
> through the same interface.
>
>
> I tried this script:
>
>
> fw="/sbin/ipfw -q"
>
> $fw nat 1 config redirect_addr 192.168.100.2 192.168.1.2 redirect_addr
> 192.168.1.2 192.168.100.2 if sk0 unreg_only reset
>
> $fw add 1001 nat 1 tcp from 192.168.100.2/32 to any via sk0 keep-state
>
> $fw add 1002 check-state
>
>
> The rule 1001 has keep-state, therefore it should process both outgoing
> tcp and incoming response packets. But the outbound packets are NATted,
> but the inbound ones are not.
>
> What is wrong, and how to fix this script?
>
>
> Thank you,
>
> Yuri
>
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."
- The Mahābhārata
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote: > What's your firewall ruleset look like? (show, don't tell) > The firewall is off for testing (the machine is only on a private network). # ipfw list 65535 allow ip from any to any > What does sysctl report on the interfaces and on arp? > > I have not changed any settings. net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.garp_rexmit_count: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.pfil_bridge: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_onlyip: 1 hw.em.eee_setting: 1 hw.em.rx_process_limit: 100 hw.em.enable_msix: 1 hw.em.sbp: 0 hw.em.smart_pwr_down: 0 hw.em.txd: 1024 hw.em.rxd: 1024 hw.em.rx_abs_int_delay: 66 hw.em.tx_abs_int_delay: 66 hw.em.rx_int_delay: 0 hw.em.tx_int_delay: 66 hw.em.disable_crc_stripping: 0 dev.em.2.wake: 0 dev.em.2.mac_stats.tso_ctx_fail: 0 dev.em.2.mac_stats.tso_txd: 0 dev.em.2.mac_stats.tx_frames_1024_1522: 3 dev.em.2.mac_stats.tx_frames_512_1023: 2 dev.em.2.mac_stats.tx_frames_256_511: 5675 dev.em.2.mac_stats.tx_frames_128_255: 4255 dev.em.2.mac_stats.tx_frames_65_127: 35563 dev.em.2.mac_stats.tx_frames_64: 918055 dev.em.2.mac_stats.mcast_pkts_txd: 0 dev.em.2.mac_stats.bcast_pkts_txd: 0 dev.em.2.mac_stats.good_pkts_txd: 963553 dev.em.2.mac_stats.total_pkts_txd: 963553 dev.em.2.mac_stats.good_octets_txd: 60423175 dev.em.2.mac_stats.good_octets_recvd: 16906 dev.em.2.mac_stats.rx_frames_1024_1522: 1 dev.em.2.mac_stats.rx_frames_512_1023: 0 dev.em.2.mac_stats.rx_frames_256_511: 0 dev.em.2.mac_stats.rx_frames_128_255: 0 dev.em.2.mac_stats.rx_frames_65_127: 235 dev.em.2.mac_stats.rx_frames_64: 0 dev.em.2.mac_stats.mcast_pkts_recvd: 0 dev.em.2.mac_stats.bcast_pkts_recvd: 0 dev.em.2.mac_stats.good_pkts_recvd: 236 dev.em.2.mac_stats.total_pkts_recvd: 236 dev.em.2.mac_stats.xoff_txd: 0 dev.em.2.mac_stats.xoff_recvd: 0 dev.em.2.mac_stats.xon_txd: 0 dev.em.2.mac_stats.xon_recvd: 0 dev.em.2.mac_stats.coll_ext_errs: 0 dev.em.2.mac_stats.alignment_errs: 0 dev.em.2.mac_stats.crc_errs: 0 dev.em.2.mac_stats.recv_errs: 0 dev.em.2.mac_stats.recv_jabber: 0 dev.em.2.mac_stats.recv_oversize: 0 dev.em.2.mac_stats.recv_fragmented: 0 dev.em.2.mac_stats.recv_undersize: 0 dev.em.2.mac_stats.recv_no_buff: 0 dev.em.2.mac_stats.missed_packets: 0 dev.em.2.mac_stats.defer_count: 0 dev.em.2.mac_stats.sequence_errors: 0 dev.em.2.mac_stats.symbol_errors: 0 dev.em.2.mac_stats.collision_count: 0 dev.em.2.mac_stats.late_coll: 0 dev.em.2.mac_stats.multiple_coll: 0 dev.em.2.mac_stats.single_coll: 0 dev.em.2.mac_stats.excess_coll: 0 dev.em.2.rxd_tail: 235 dev.em.2.rxd_head: 236 dev.em.2.txd_tail: 127 dev.em.2.txd_head: 127 dev.em.2.fifo_reset: 0 dev.em.2.fifo_workaround: 0 dev.em.2.fc_low_water: 45604 dev.em.2.fc_high_water: 47104 dev.em.2.rx_control: 32794 dev.em.2.device_control: 1086325321 dev.em.2.watchdog_timeouts: 0 dev.em.2.rx_overruns: 0 dev.em.2.tx_desc_fail2: 0 dev.em.2.tx_desc_fail1: 0 dev.em.2.tx_dma_fail: 0 dev.em.2.dropped: 0 dev.em.2.mbuf_defrag_fail: 0 dev.em.2.cluster_alloc_fail: 0 dev.em.2.flow_control: 3 dev.em.2.rx_processing_limit: 100 dev.em.2.itr: 488 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_int_delay: 66 dev.em.2.rx_int_delay: 0 dev.em.2.nvm: -1 dev.em.2.%parent: pci2 dev.em.2.%pnpinfo: vendor=0x8086 device=0x100f subvendor=0x15ad subdevice=0x0750 class=0x02 dev.em.2.%location: slot=3 function=0 dbsf=pci0:2:3:0 handle=\_SB_.PCI0.P2P0.S4F0 dev.em.2.%driver: em dev.em.2.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.1.0 dev.em.1.wake: 0 dev.em.1.mac_stats.tso_ctx_fail: 0 dev.em.1.mac_stats.tso_txd: 0 dev.em.1.mac_stats.tx_frames_1024_1522: 1 dev.em.1.mac_stats.tx_frames_512_1023: 0 dev.em.1.mac_stats.tx_frames_256_511: 0 dev.em.1.mac_stats.tx_frames_128_255: 0 dev.em.1.mac_stats.tx_frames_65_127: 13 dev.em.1.mac_stats.tx_frames_64: 222 dev.em.1.mac_stats.mcast_pkts_txd: 0 dev.em.1.mac_stats.bcast_pkts_txd: 0 dev.em.1.mac_stats.good_pkts_txd: 236 dev.em.1.mac_stats.total_pkts_txd: 236 dev.em.1.mac_stats.good_octets_txd: 15962 dev.em.1.mac_stats.good_octets_recvd: 5286574431 dev.em.1.mac_stats.rx_frames_1024_1522: 2876152 dev.em.1.mac_stats.rx_frames_512_1023: 269810 dev.em.1.mac_stats.rx_frames_256_511: 605978 dev.em.1.mac_stats.rx_frames_128_255: 1879331 dev.em.1.mac_stats.rx_frames_65_127: 3179015 dev.em.1.mac_stats.rx_frames_64: 6 dev.em.1.mac_stats.mcast_pkts_recvd: 0 dev.em.1.mac_stats.bcast_pkts_recvd: 0 dev.em.1.mac_stats.good_pkts_recvd: 8809664 dev.em.1.mac_stats.total_pkts_recvd: 8816562 dev.em.1.mac_stats.xoff_txd: 0 dev.em.1.mac_stats.xoff_recvd: 0 dev.em.1.mac_stats.xon_txd: 0 dev.em.1.mac_stats.xon_recvd: 0 dev.em.
Re: Bridge Not Forwarding ARP
09.07.2019 0:19, Dan Lists wrote: > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio wrote: > >> What's your firewall ruleset look like? (show, don't tell) > The firewall is off for testing (the machine is only on a private network). > # ipfw list > 65535 allow ip from any to any >> What does sysctl report on the interfaces and on arp? > I have not changed any settings. Show output of ifconfig for the bridge and for its members, too. I suppose some misconfiguration like IP address assigned to member interfaces that is wrong. All IP addresses need to be moved to the bridge interface itself. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote: 09.07.2019 0:19, Dan Lists wrote: > > > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio > wrote: > > > >> What's your firewall ruleset look like? (show, don't tell) > > The firewall is off for testing (the machine is only on a private > network). > > # ipfw list > > 65535 allow ip from any to any > >> What does sysctl report on the interfaces and on arp? > > I have not changed any settings. > > Show output of ifconfig for the bridge and for its members, too. > I suppose some misconfiguration like IP address assigned to member > interfaces that is wrong. > All IP addresses need to be moved to the bridge interface itself. > > Does 'ip' in ipfw match arp packets? -- "Well," Brahmā said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mahābhārata ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
On Mon, Jul 8, 2019 at 12:43 PM Michael Sierchio wrote: > > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein > wrote: > > 09.07.2019 0:19, Dan Lists wrote: >> >> > On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio >> wrote: >> > >> >> What's your firewall ruleset look like? (show, don't tell) >> > The firewall is off for testing (the machine is only on a private >> network). >> > # ipfw list >> > 65535 allow ip from any to any >> >> What does sysctl report on the interfaces and on arp? >> > I have not changed any settings. >> >> Show output of ifconfig for the bridge and for its members, too. >> I suppose some misconfiguration like IP address assigned to member >> interfaces that is wrong. >> All IP addresses need to be moved to the bridge interface itself. >> >> > Does 'ip' in ipfw match arp packets? > It is my understanding that ARP packets are not filtered. That behavior can be changed by setting net.link.bridge.ipfw_arp=1. ARP packets are supposed to be forwarded by default. That worked with FreeBSD 8.4. -- > > "Well," Brahmā said, "even after ten thousand explanations, a fool is no > wiser, but an intelligent person requires only two thousand five hundred." > > - The Mahābhārata > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
09.07.2019 0:43, Michael Sierchio wrote: > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein wrote: > > 09.07.2019 0:19, Dan Lists wrote: >> >>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio >> wrote: >>> What's your firewall ruleset look like? (show, don't tell) >>> The firewall is off for testing (the machine is only on a private >> network). >>> # ipfw list >>> 65535 allow ip from any to any What does sysctl report on the interfaces and on arp? >>> I have not changed any settings. >> >> Show output of ifconfig for the bridge and for its members, too. >> I suppose some misconfiguration like IP address assigned to member >> interfaces that is wrong. >> All IP addresses need to be moved to the bridge interface itself. >> >> > Does 'ip' in ipfw match arp packets? We have net.link.bridge.ipfw_arp that defaults to 0 (false): $ sysctl -d net.link.bridge.ipfw_arp net.link.bridge.ipfw_arp: Filter ARP packets through IPFW layer2 If one changes it to 1 so ipfw would get bridged ARP frames, then answer to your question should depend on value of net.link.ether.ipfw (0 by default) as ARP packets have no IP header. So if you change so many sysctls, you will be able to filter ARP frames with "ip" keyword as "ip" equals to "all" in ipfw. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
On Mon, Jul 8, 2019 at 11:22 AM Eugene Grosbein wrote: > 09.07.2019 0:43, Michael Sierchio wrote: > > > On Mon, Jul 8, 2019 at 10:33 AM Eugene Grosbein > wrote: > > > > 09.07.2019 0:19, Dan Lists wrote: > >> > >>> On Mon, Jul 8, 2019 at 11:55 AM Michael Sierchio > >> wrote: > >>> > What's your firewall ruleset look like? (show, don't tell) > >>> The firewall is off for testing (the machine is only on a private > >> network). > >>> # ipfw list > >>> 65535 allow ip from any to any > What does sysctl report on the interfaces and on arp? > >>> I have not changed any settings. > >> > >> Show output of ifconfig for the bridge and for its members, too. > >> I suppose some misconfiguration like IP address assigned to member > >> interfaces that is wrong. > >> All IP addresses need to be moved to the bridge interface itself. > >> > >> > > Does 'ip' in ipfw match arp packets? > > We have net.link.bridge.ipfw_arp that defaults to 0 (false): > > $ sysctl -d net.link.bridge.ipfw_arp > net.link.bridge.ipfw_arp: Filter ARP packets through IPFW layer2 > > If one changes it to 1 so ipfw would get bridged ARP frames, > then answer to your question should depend on value of net.link.ether.ipfw > (0 by default) > as ARP packets have no IP header. So if you change so many sysctls, you > will be able > to filter ARP frames with "ip" keyword as "ip" equals to "all" in ipfw. > > Right, thanks, and Dan's sysctl output has net.link.bridge.ipfw_arp: 0 -- "Well," Brahmā said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mahābhārata ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Bridge Not Forwarding ARP
I had this exact issue while virtualbox had a guest network adapter bridged to the external interface that the FreeBDS bridge0 interface was bridged to. If I shutdown the VMs, ARP magically started working bidirectionally, and after restarting the VMs it failed again. My fix was eventually to just have 2 external NICs; one exclusively for the virtualbox systems. I have no idea if you have a virtualbox guest present, but if so that was my fix. The issue occurred on both igb and re NICs. -Joseph On 2019-07-08 12:13, Dan Lists wrote: > I have a server running FreeBSD 11.2 that I am wanting to use as a bridged > firewall. I have it set up and it mostly works. The problem is that ARP > replies are not being forwarded from the outside interface to the inside > interface. It appears to be working in the other direction. I see the > ARP request go out on the outside interface and the reply arrives back at > the outside interface. The ARP reply is never getting to the bridge or to > the inside interface. > > The firewall server and the device behind it are in ESX. I think I've > worked all the ESX issues out. When I manually add an ARP entry everything > works. I've done this before with a physical server running FreeBSD 8.4 > and it works as expected. The differences are physical vs virtual, and > 8.4 vs 11.2. > > I'm at a loss as to why it is not working. I've searched the web and > found noting. If anyone could offer suggestions on how to fix this or > begin to debug it I would greatly appreciate it. > > Thanks, > > Dan > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238789] panic: mutex so_rcv not owned at /usr/src/sys/kern/uipc_socket.c:2359
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238789 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable11?, |mfc-stable11+, |mfc-stable12? |mfc-stable12+ Keywords|needs-qa| -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238642] netmap: fix kernel pointer printing in netmap_generic.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238642 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable11?, ||mfc-stable12? Severity|Affects Only Me |Affects Some People Resolution|FIXED |--- CC||n...@freebsd.org Assignee|n...@freebsd.org |vmaffi...@freebsd.org Status|Closed |In Progress Keywords||security --- Comment #2 from Kubilay Kocak --- Re-open pending MFC -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238641] netmap: Remove pointer printing in netmap_mem2.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238641 Kubilay Kocak changed: What|Removed |Added Keywords||security Resolution|FIXED |--- Severity|Affects Only Me |Affects Some People Status|Closed |In Progress Assignee|n...@freebsd.org |vmaffi...@freebsd.org Flags||mfc-stable11?, ||mfc-stable12? --- Comment #3 from Kubilay Kocak --- Reopen pending MFC -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238324] Add XG-C100C/AQtion AQC107 10GbE NIC driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238324 Kubilay Kocak changed: What|Removed |Added Severity|Affects Many People |Affects Some People CC||ko...@freebsd.org Status|New |Open Keywords||feature --- Comment #4 from Kubilay Kocak --- I have a port WIP for this, which may be the best place for the network driver in the first instance. At last test it was failing to build on one supported base branch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 WHR changed: What|Removed |Added Resolution|Not A Bug |--- Status|Closed |Open --- Comment #7 from WHR --- (In reply to Cy Schubert from comment #5) I has successfully reproduced this bug in kernel version 13.0-CURRENT r349753. I don't known how does you believe this bug could disappear without actual code change. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 --- Comment #8 from WHR --- (In reply to Cy Schubert from comment #5) > there is no need for this patch. It already works. Why? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 WHR changed: What|Removed |Added Version|12.0-STABLE |CURRENT -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 238796] ipfilter: fix unremovable rules and rules checksum for comparison
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796 Cy Schubert changed: What|Removed |Added Resolution|--- |Not A Bug Status|Open|Closed --- Comment #9 from Cy Schubert --- cwfw# echo "pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/24 port = 22 to any" | ipf -f - cwfw# ipfstat -ion | grep 'pass in quick on fxp0 to sk0:10.1.1.1 inet' @212 pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/24 port = ssh to any cwfw# echo "pass in quick on fxp0 to sk0:10.1.1.1 inet proto tcp from 192.168.0.0/24 port = 22 to any" | ipf -r -f - cwfw# ipfstat -ion | grep 'pass in quick on fxp0 to sk0:10.1.1.1 inet' cwfw# cwfw# uname -a FreeBSD cwfw 13.0-CURRENT FreeBSD 13.0-CURRENT #407 r349853M: Mon Jul 8 18:28:18 PDT 2019 root@cwfw:/export/obj/opt/src/svn-current/amd64.amd64/sys/PROD2 amd64 cwfw# I am unable to reproduce this on my production firewall. It is likely your problem is due to one of your custom patches. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
