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 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 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, but you need patch sources and rebuild kernel/module) is that `libalias` uses only 4096 buckets in state hashtable by default. So it could saturate 1GBps link if you have 10 TCP connections, but it could not saturate 100Mbit if your have, say, 100K UDP streams. I don't know about pf nat. ___ 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 243392] if_vmx(4): Input buffer corruption
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243392 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable11? Status|Open|In Progress CC||n...@freebsd.org Keywords|needs-qa| Assignee|n...@freebsd.org |pkel...@freebsd.org --- Comment #15 from Kubilay Kocak --- ^Triage: Assign to committer resolving, pending MFC. If this doesn't need to go to stable/11, set mfc-stable11 to - Thanks Patrick! -- 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 243126] if_vmx(4): iflib: Assertion fl->ifl_cidx == cidx failed at /usr/src/sys/net/iflib.c:2531
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243126 Kubilay Kocak changed: What|Removed |Added Assignee|n...@freebsd.org |pkel...@freebsd.org Keywords|needs-qa| Summary|iflib: Assertion|if_vmx(4): iflib: Assertion |fl->ifl_cidx == cidx failed |fl->ifl_cidx == cidx failed |at |at |/usr/src/sys/net/iflib.c:25 |/usr/src/sys/net/iflib.c:25 |31 with if_vmx(4) |31 Flags||mfc-stable11? Status|Open|In Progress --- Comment #12 from Kubilay Kocak --- ^Triage: Assign to committer resolving, pending MFC. If this doesn't need to go to stable/11, set mfc-stable11 to - Thanks Patrick! -- You are receiving this mail because: You are the assignee for the bug. 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 240608] if_vmx(4): iflib - Panic with INVARIANTS: Memory modified after free (12.1-pre-QA)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240608 Kubilay Kocak changed: What|Removed |Added Keywords|needs-qa| Status|Open|In Progress Assignee|n...@freebsd.org |pkel...@freebsd.org --- Comment #17 from Kubilay Kocak --- ^Triage: Assign to committer resolving, pending MFC. If this doesn't need to go to stable/11, set mfc-stable11 to - Thanks Patrick! -- 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"
Re: IPv6 in jails
Jacques Foucry wrote:
>
> >
> > Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> > wrong?
>
> Suppose to work, and work for me.
> >
> > Here is a test jail:
> >
> > test4 {
> > path = /d02/jails/test4 ;
> > mount.devfs;
> > ip4 = new;
> > ip6 = new;
> > ip4.addr = 192.168.4.204/24;
> > ip6.addr = 2001:470:ecba:3::4/64;
> > host.hostname = test4.vas.sibptus.ru ;
> > interface = re1 ;
> > allow.raw_sockets = true ;
> > exec.start = "/bin/sh /etc/rc";
> > exec.stop = "/bin/sh /etc/rc.shutdown";
> > }
>
>
> Well there is a difference between your config and mine:
>
> ip6.addr="em0|2a01:4f9:4a:1fd8::16/64";
>
> In my config there is the interface to use (em0 in my case, re1 should be in
> yours)
I have a more generic "interface = re1" statement, but replacing it with
ip6.addr = "re1|2001:470:ecba:3::4" did not produce any effect on the
jailed daemons.
Of course the IPv6 address is present on re1 in both cases (my
syntax and your syntax). When the jail is stopped, the address goes
away.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: IPv6 in jails
Bjoern A. Zeeb wrote: > On 18 Mar 2020, at 15:50, Victor Sudakov wrote: > > > > If sshd in the host is configured to listen on all available > > > interfaces and > > > addresses (the default) then it will catch your jails IP too. > > > > Why is it not catching the 192.168.4.204 address then? > > > > > You must configure sshd in the host to listen only on hosts IP and > > > then you > > > will connect to the jails sshd. > > > > OK, I've stopped the sshd on the host entirely, and restarted the jails. > > Why am I still not seeing the jailed sshd listening on tcp6? > > Can you check the logfile inside the jail and see if it complains? It turns out it does: Mar 19 08:52:35 test4 sshd[27210]: error: Bind to port 22 on :: failed: Can't assign requested address. > > Can you then do a jexec test4 and run service sshd restart and see if it > starts working? It turns out it does: root@test4:/ # sockstat -l USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sendmail 28249 3 tcp4 192.168.4.204:25 *:* root sshd 28246 3 tcp6 2001:470:ecba:3::4:22 *:* root sshd 28246 4 tcp4 192.168.4.204:22 *:* root syslogd28181 5 udp4 192.168.4.204:514 *:* root syslogd28181 6 dgram /var/run/log root syslogd28181 7 dgram /var/run/logpriv same with other daemons: root@test4:/ # service syslogd restart Stopping syslogd. Waiting for PIDS: 28181. Starting syslogd. root@test4:/ # sockstat -l USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root syslogd28678 5 udp6 2001:470:ecba:3::4:514 *:* root syslogd28678 6 udp4 192.168.4.204:514 *:* root syslogd28678 7 dgram /var/run/log root syslogd28678 8 dgram /var/run/logpriv > If it does, can you add a > > exec.start += "sleep 2 "; > > to your config OK, I've added it to the configs of 3 experimental jails. > and see if your problem goes away? It goes away partially (only for sshd in 2 of the 3 available jails), and not for syslogd in any of the 3 available jails. Restarting the daemons from within the jail fixes the problem. An example from a problem jail: root@vas:~ # jexec test5 root@test5:/ # sockstat -l USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sendmail 29495 3 tcp4 192.168.4.205:25 *:* root sshd 29492 3 tcp4 192.168.4.205:22 *:* root syslogd29427 5 udp4 192.168.4.205:514 *:* root syslogd29427 6 dgram /var/run/log root syslogd29427 7 dgram /var/run/logpriv root@test5:/ # service sshd restart Performing sanity check on sshd configuration. Stopping sshd. Waiting for PIDS: 29492, 29492. Performing sanity check on sshd configuration. Starting sshd. root@test5:/ # sockstat -l USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 29838 3 tcp6 2001:470:ecba:3::5:22 *:* root sshd 29838 4 tcp4 192.168.4.205:22 *:* root sendmail 29495 3 tcp4 192.168.4.205:25 *:* root syslogd29427 5 udp4 192.168.4.205:514 *:* root syslogd29427 6 dgram /var/run/log root syslogd29427 7 dgram /var/run/logpriv root@test5:/ # service syslogd restart Stopping syslogd. Waiting for PIDS: 29427. Starting syslogd. root@test5:/ # sockstat -l USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root syslogd29858 5 udp6 2001:470:ecba:3::5:514 *:* root syslogd29858 6 udp4 192.168.4.205:514 *:* root syslogd29858 7 dgram /var/run/log root syslogd29858 8 dgram /var/run/logpriv root sshd 29838 3 tcp6 2001:470:ecba:3::5:22 *:* root sshd 29838 4 tcp4 192.168.4.205:22 *:* root cron 29502 5 dgram (not connected) smmspsendmail 29498 3 dgram (not connected) root sendmail 29495 3 tcp4 192.168.4.205:25 *:* root sendmail 29495 4 dgram (not connected) root@test5:/ # > If it does, the reason is > that you configure an IPv6 address to an interface and DUD has not yet > completed by the time sshd or other daemons start. Giving it the 2 seconds > avoids this problem and the address is usable at that time. There is obviously a race somewhere, but the 2 second sleep does not eliminate it entirely. Thank you for the hint in the right direction, what would you suggest further? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: IPv6 in jails
On 18 Mar 2020, at 15:50, Victor Sudakov wrote: If sshd in the host is configured to listen on all available interfaces and addresses (the default) then it will catch your jails IP too. Why is it not catching the 192.168.4.204 address then? You must configure sshd in the host to listen only on hosts IP and then you will connect to the jails sshd. OK, I've stopped the sshd on the host entirely, and restarted the jails. Why am I still not seeing the jailed sshd listening on tcp6? Can you check the logfile inside the jail and see if it complains? Can you then do a jexec test4 and run service sshd restart and see if it starts working? If it does, can you add a exec.start += "sleep 2 "; to your config and see if your problem goes away? If it does, the reason is that you configure an IPv6 address to an interface and DUD has not yet completed by the time sshd or other daemons start. Giving it the 2 seconds avoids this problem and the address is usable at that time. Your theory is probably incorrect. The theory is incorrect. The jail will always take precedence (at least since the multi-IP jail patches in 2008). /bz ___ 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: IPv6 in jails
Le mercredi 18 mars 2020 à 22:15:56 (+0700), Victor Sudakov à écrit:
> Dear Colleagues,
Hello Victor,
>
> Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> wrong?
Suppose to work, and work for me.
>
> Here is a test jail:
>
> test4 {
> path = /d02/jails/test4 ;
> mount.devfs;
> ip4 = new;
> ip6 = new;
> ip4.addr = 192.168.4.204/24;
> ip6.addr = 2001:470:ecba:3::4/64;
> host.hostname = test4.vas.sibptus.ru ;
> interface = re1 ;
> allow.raw_sockets = true ;
> exec.start = "/bin/sh /etc/rc";
> exec.stop = "/bin/sh /etc/rc.shutdown";
> }
Well there is a difference between your config and mine:
ip6.addr="em0|2a01:4f9:4a:1fd8::16/64";
In my config there is the interface to use (em0 in my case, re1 should be in
yours)
>
> However when I look from inside the jail, I see the daemons listening
> only on IPv4:
>
> root@test4:/ # sockstat -l
> USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
>
> root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
> root sshd 17175 3 tcp4 192.168.4.204:22 *:*
> root syslogd17110 5 udp4 192.168.4.204:514 *:*
>
> If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead
> of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
> available inside the jail).
Hope my small experience can help you.
--
Jacques Foucry
signature.asc
Description: PGP signature
Re: IPv6 in jails
Bjoern A. Zeeb wrote:
> >
> > Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> > wrong?
> >
> > Here is a test jail:
> >
> > test4 {
> > path = /d02/jails/test4 ;
> > mount.devfs;
> > ip4 = new;
> > ip6 = new;
> > ip4.addr = 192.168.4.204/24;
> > ip6.addr = 2001:470:ecba:3::4/64;
>
> I usually do something like this:
>
> ip6.addr += "lo0|2001:db8:1234:5678::ef/128";
>
> to add the single address out of a /64 to the loopback interface on the host
> and then pass it through to the jail. The /64 however is actually routed to
> my host so might not work if you have the /64 on the physical interface.
>
> Given it is a jail without vnet you cannot assign a /64 to the jail, you
> want to just specify the address usually (plainly or as /128).
Bjoern, I've just changed "ip6.addr = 2001:470:ecba:3::4/64" to
"ip6.addr = 2001:470:ecba:3::4/128" per your advice, and restarted the
jails, without any visible result. The daemons inside still listen only
on tcp4:
root@test4:/ # sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 18711 3 tcp4 192.168.4.204:25 *:*
root sshd 18708 3 tcp4 192.168.4.204:22 *:*
root syslogd18643 5 udp4 192.168.4.204:514 *:*
root syslogd18643 6 dgram /var/run/log
root syslogd18643 7 dgram /var/run/logpriv
root@test4:/ #
>
> One thing to check first is ifconfig inside the jail does see the
> address?
Still does, but no use:
root@test4:/ # ifconfig re1
re1: flags=8843 metric 0 mtu 1500
description: Inside
options=8209b
ether c4:12:f5:33:c9:7c
inet 192.168.4.204/24 broadcast 192.168.4.255
inet6 2001:470:ecba:3::4/128
media: Ethernet autoselect (none)
status: no carrier
nd6 options=21
root@test4:/ #
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: IPv6 in jails
Miroslav Lachman wrote:
> Victor Sudakov wrote on 2020/03/18 16:15:
> >
> > Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> > wrong?
> >
> > Here is a test jail:
> >
> > test4 {
> > path = /d02/jails/test4 ;
> > mount.devfs;
> > ip4 = new;
> > ip6 = new;
> > ip4.addr = 192.168.4.204/24;
> > ip6.addr = 2001:470:ecba:3::4/64;
> > host.hostname = test4.vas.sibptus.ru ;
> > interface = re1 ;
> > allow.raw_sockets = true ;
> > exec.start = "/bin/sh /etc/rc";
> > exec.stop = "/bin/sh /etc/rc.shutdown";
> > }
> >
> > However when I look from inside the jail, I see the daemons listening
> > only on IPv4:
> >
> > root@test4:/ # sockstat -l
> > USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
> > root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
> > root sshd 17175 3 tcp4 192.168.4.204:22 *:*
> > root syslogd17110 5 udp4 192.168.4.204:514 *:*
> >
> > If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead
> > of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
> > available inside the jail).
>
> If sshd in the host is configured to listen on all available interfaces and
> addresses (the default) then it will catch your jails IP too.
Why is it not catching the 192.168.4.204 address then?
> You must configure sshd in the host to listen only on hosts IP and then you
> will connect to the jails sshd.
OK, I've stopped the sshd on the host entirely, and restarted the jails.
Why am I still not seeing the jailed sshd listening on tcp6?
root@test4:/ # sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN
ADDRESS
root sendmail 17995 3 tcp4 192.168.4.204:25 *:*
root sshd 17992 3 tcp4 192.168.4.204:22 *:*
root syslogd17927 5 udp4 192.168.4.204:514 *:*
root syslogd17927 6 dgram /var/run/log
root syslogd17927 7 dgram /var/run/logpriv
root@test4:/ #
Your theory is probably incorrect.
>
> What is you sshd_config in the host and in the jail?
The sshd on the host has been stopped now.
The sshd_config in the jail is the FreeBSD default one.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: IPv6 in jails
Steve O'Hara-Smith wrote: > On Wed, 18 Mar 2020 22:15:56 +0700 > Victor Sudakov wrote: > > > If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead > > of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not > > available inside the jail). > > Having the host listening on an address will stop any jails from > being able to listen on that address. You need to stop the host services > listening on the jail's IPv6 address. I don't understand you. What's the difference between "ip4.addr = 192.168.4.204/24" and "ip6.addr = 2001:470:ecba:3::4/64" in this configuration? Should be none. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ signature.asc Description: PGP signature
Re: IPv6 in jails
Victor Sudakov wrote on 2020/03/18 16:15:
Dear Colleagues,
Is IPv6 in jails supposed to work? Does not work for me, what am I doing
wrong?
Here is a test jail:
test4 {
path = /d02/jails/test4 ;
mount.devfs;
ip4 = new;
ip6 = new;
ip4.addr = 192.168.4.204/24;
ip6.addr = 2001:470:ecba:3::4/64;
host.hostname = test4.vas.sibptus.ru ;
interface = re1 ;
allow.raw_sockets = true ;
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
}
However when I look from inside the jail, I see the daemons listening
only on IPv4:
root@test4:/ # sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
root sshd 17175 3 tcp4 192.168.4.204:22 *:*
root syslogd17110 5 udp4 192.168.4.204:514 *:*
If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead
of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
available inside the jail).
If sshd in the host is configured to listen on all available interfaces
and addresses (the default) then it will catch your jails IP too.
You must configure sshd in the host to listen only on hosts IP and then
you will connect to the jails sshd.
What is you sshd_config in the host and in the jail? Following the
configuration directives must be set right.
Port
AddressFamily
ListenAddress
Miroslav Lachman
___
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: IPv6 in jails
On Wed, 18 Mar 2020 22:15:56 +0700 Victor Sudakov wrote: > If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead > of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not > available inside the jail). Having the host listening on an address will stop any jails from being able to listen on that address. You need to stop the host services listening on the jail's IPv6 address. -- Steve O'Hara-Smith ___ 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: IPv6 in jails
Bjoern A. Zeeb wrote:
> >
> > Is IPv6 in jails supposed to work? Does not work for me, what am I doing
> > wrong?
> >
> > Here is a test jail:
> >
> > test4 {
> > path = /d02/jails/test4 ;
> > mount.devfs;
> > ip4 = new;
> > ip6 = new;
> > ip4.addr = 192.168.4.204/24;
> > ip6.addr = 2001:470:ecba:3::4/64;
>
> I usually do something like this:
>
> ip6.addr += "lo0|2001:db8:1234:5678::ef/128";
>
> to add the single address out of a /64 to the loopback interface on the host
> and then pass it through to the jail. The /64 however is actually routed to
> my host so might not work if you have the /64 on the physical interface.
But the same syntax for IPv4 (192.168.4.204/24) works fine! The address
192.168.4.204 is successfully assigned to the jail.
>
> Given it is a jail without vnet you cannot assign a /64 to the jail, you
> want to just specify the address usually (plainly or as /128).
Why is that? I can assign an IPv4 /24 to the jail but cannot assign an IPv6 /64
?
The prefix length should be irrelevant, as it is irrelevant in the IPv4
case.
>
> > host.hostname = test4.vas.sibptus.ru ;
> > interface = re1 ;
> > allow.raw_sockets = true ;
> > exec.start = "/bin/sh /etc/rc";
> > exec.stop = "/bin/sh /etc/rc.shutdown";
> > }
> >
> > However when I look from inside the jail, I see the daemons listening
> > only on IPv4:
> >
> > root@test4:/ # sockstat -l
> > USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN
> > ADDRESS
> > root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
> > root sshd 17175 3 tcp4 192.168.4.204:22 *:*
> > root syslogd17110 5 udp4 192.168.4.204:514 *:*
> >
> > If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead
> > of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
> > available inside the jail).
>
> One thing to check first is ifconfig inside the jail does see the address?
Yes, it does:
root@test4:/ # ifconfig re1
re1: flags=8843 metric 0 mtu
1500
description: Inside
options=8209b
ether c4:12:f5:33:c9:7c
inet 192.168.4.204/24 broadcast 192.168.4.255
inet6 2001:470:ecba:3::4/64
media: Ethernet autoselect (none)
status: no carrier
nd6 options=21
root@test4:/ #
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
Re: IPv6 in jails
On 18 Mar 2020, at 15:15, Victor Sudakov wrote:
Dear Colleagues,
Is IPv6 in jails supposed to work? Does not work for me, what am I
doing
wrong?
Here is a test jail:
test4 {
path = /d02/jails/test4 ;
mount.devfs;
ip4 = new;
ip6 = new;
ip4.addr = 192.168.4.204/24;
ip6.addr = 2001:470:ecba:3::4/64;
I usually do something like this:
ip6.addr += "lo0|2001:db8:1234:5678::ef/128";
to add the single address out of a /64 to the loopback interface on the
host and then pass it through to the jail. The /64 however is actually
routed to my host so might not work if you have the /64 on the physical
interface.
Given it is a jail without vnet you cannot assign a /64 to the jail, you
want to just specify the address usually (plainly or as /128).
host.hostname = test4.vas.sibptus.ru ;
interface = re1 ;
allow.raw_sockets = true ;
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
}
However when I look from inside the jail, I see the daemons listening
only on IPv4:
root@test4:/ # sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN
ADDRESS
root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
root sshd 17175 3 tcp4 192.168.4.204:22 *:*
root syslogd17110 5 udp4 192.168.4.204:514 *:*
If I "ssh 2001:470:ecba:3::4" from outside, I get into the host
instead
of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
available inside the jail).
One thing to check first is ifconfig inside the jail does see the
address?
/bz
___
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"
IPv6 in jails
Dear Colleagues,
Is IPv6 in jails supposed to work? Does not work for me, what am I doing
wrong?
Here is a test jail:
test4 {
path = /d02/jails/test4 ;
mount.devfs;
ip4 = new;
ip6 = new;
ip4.addr = 192.168.4.204/24;
ip6.addr = 2001:470:ecba:3::4/64;
host.hostname = test4.vas.sibptus.ru ;
interface = re1 ;
allow.raw_sockets = true ;
exec.start = "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
}
However when I look from inside the jail, I see the daemons listening
only on IPv4:
root@test4:/ # sockstat -l
USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 17178 3 tcp4 192.168.4.204:25 *:*
root sshd 17175 3 tcp4 192.168.4.204:22 *:*
root syslogd17110 5 udp4 192.168.4.204:514 *:*
If I "ssh 2001:470:ecba:3::4" from outside, I get into the host instead
of the jail (because 2001:470:ecba:3::4 *is* assigned to re1, but not
available inside the jail).
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
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 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, but you need patch sources and rebuild kernel/module) is that `libalias` uses only 4096 buckets in state hashtable by default. So it could saturate 1GBps link if you have 10 TCP connections, but it could not saturate 100Mbit if your have, say, 100K UDP streams. I don't know about pf nat. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
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. > > Speedtests usually give me 700 Mbps down/900 Mbps up, and 250-400 Mbps > down/800 Mbps up during the Coronavirus crisis. However, I'm having problems > with an application (Tor relays) where I am not able to use a lot of > bandwidth for Tor, Coronavirus-related telecommuting or not. My Tor server is > separate from my firewall. > > 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 NAT, even on quite modest hardware. Are you sure the NAT code is the bottleneck? Regards, Kristof ___ 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"
