On 9/11/2020 12:15 PM, Scheffenegger, Richard wrote:
Thank you for the quick feedback.
On a related note - it just occurred to me, that the PCP functionality could be
extended to make more effective use of PFC (priority flow control) without
explicitly managing it on an application level
On 8/10/2020 11:58 PM, Neel Chauhan wrote:
Hi freebsd-net@,
Sorry if this is the wrong place to post this.
In case you were wondering, I am responsible for patches like r357092
(IPFW/libalias RFC6598, original idea), r363403 and r362900 (related
to routing KPI, suggested by melifaro@).
On 11/21/2019 9:10 AM, Victor Sudakov wrote:
Dear Colleagues,
A quick question about pf from an ipfw user.
Suppose I have three interfaces: $outside, $inside and $dmz. If I want
to block any traffic from $dmz to $inside, unless it is
1. Return traffic from $inside to $dmz
2. ICMP traffic in
On 10/9/2019 2:50 PM, Julian Elischer wrote:
On 10/9/19 2:34 AM, Julien Cigar wrote:
On Tue, Oct 08, 2019 at 01:05:37PM -0700, Julian Elischer wrote:
On 10/8/19 8:58 AM, Julien Cigar wrote:
On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
Hi Julien,
Hi Matthew,
It's
On 10/9/2019 4:10 AM, Julien Cigar wrote:
On Tue, Oct 08, 2019 at 11:22:51AM -0500, Matthew Grooms wrote:
On 10/8/2019 10:58 AM, Julien Cigar wrote:
On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
Hi Julien,
Hi Matthew,
It's not clear why you are trying to assign multiple
On 10/8/2019 10:58 AM, Julien Cigar wrote:
On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
Hi Julien,
Hi Matthew,
It's not clear why you are trying to assign multiple carp IP address to
two different interfaces from within the same IP subnet. Are you trying
to fail over a 2nd
Hi Julien,
It's not clear why you are trying to assign multiple carp IP address to
two different interfaces from within the same IP subnet. Are you trying
to fail over a 2nd carp address or are you trying to improve
throughput/redundancy? If you just want to fail over a 2nd carp address,
On 6/8/2016 10:15 AM, David DeSimone wrote:
One of the purposes of the CARP announcements is to announce the
location of the virtual mac address to the upstream switch fabric.
Since CARP uses a virtual mac that floats between multiple ports, you
need to have the CARP master continually assert
Hi Niklaas,
Rewriting the multicast destination would be a neat trick, but sadly no.
You can't rewrite a destination address on egress. Using a route-to rule
would only modify the destination MAC address. If you were using
OpenBSD, you would switch from multicast to unicast using the syncpeer
On 2/3/2016 6:47 PM, Matthew Grooms wrote:
This turned out to be another issue that was patched in head but not
back ported to stable. I can't explain why it didn't get tripped when
GRE tunnels were disabled. With the patch applied, I can reload my
rule sets again without crashing ...
https
On 2/3/2016 4:56 PM, Matthew Grooms wrote:
All,
I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that
I could avoid the local patching required to keep it up and running.
Unfortunately, it crashes whenever I reload my pf firewall rule set.
If I remove the GRE tunnel
All,
I recently upgraded a pair of 10.0-RELEASE firewalls in the hope that I
could avoid the local patching required to keep it up and running.
Unfortunately, it crashes whenever I reload my pf firewall rule set. If
I remove the GRE tunnel configurations from rc.conf, it happily reloads
the
On 1/22/2016 3:35 PM, Nick Rogers wrote:
On Thu, Jan 21, 2016 at 11:44 AM, Matthew Grooms <mgro...@shrew.net> wrote:
# pfctl -si
Status: Enabled for 0 days 02:25:41 Debug: Urgent
State Table Total Rate
current entries
On 1/21/2016 11:04 AM, Nick Rogers wrote:
On Wed, Jan 20, 2016 at 2:01 PM, Matthew Grooms<mgro...@shrew.net> wrote:
All,
I have a curious problem with a lightly loaded pair of pf firewall running
on FreeBSD 10.2-RELEASE. I'm noticing TCP entries are disappearing from
the state
All,
I have a curious problem with a lightly loaded pair of pf firewall
running on FreeBSD 10.2-RELEASE. I'm noticing TCP entries are
disappearing from the state table for no good reason that I can see. The
entry limit is set to 10 and I never see the system go over about
7 entries,
On 4/22/2015 8:34 PM, Scott O'Connell wrote:
I tried your suggestions.
I was successful in changing the vmhost01 bridge to include vlan100
and tap0, and in the vm (dev) binding the address directly to vtnet0.
On the VMHOST:
tap0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
On 4/22/2015 11:02 AM, Scott O'Connell wrote:
I'm very new to bhyve and am having an issue. I'm trying to get VM's
and VLAN's working.
I'm able to get VLAN's working in a VM, but the VM and the VMHOST,
can't communicate with each other on the same vlan.
Using 10.1-RELEASE-p9 for both
Ok, I feel a little silly. These commands do not work without the CAfile
specified on freebsd 8.x or 9.x either. Sorry for the noise.
-Matthew
On 11/10/2014 2:19 PM, Matthew Grooms wrote:
All,
I am seeing a problem with certificate checking on several stock FreeBSD
10.0-RELEASE-p12 hosts
On 10/23/2014 5:56 AM, Andrey V. Elsukov wrote:
On 22.10.2014 23:28, Matthew Grooms wrote:
On 10/21/2014 1:39 PM, Kyle Williams wrote:
On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote:
Hey Kyle,
Thanks for lending a hand. I tested a few myself last night but had no
luck. This morning I
On 10/21/2014 1:39 PM, Kyle Williams wrote:
On Tue Oct 21 11:35:15 2014, Matthew Grooms wrote:
Hey Kyle,
Thanks for lending a hand. I tested a few myself last night but had no
luck. This morning I received an email off list that pointed to a patch
that was merged to 10 stable. It sounds
On 10/21/2014 11:06 AM, Kyle Williams wrote:
Hello,
I'm currently using 10.0, IPSEC, racoon, enc, and pf between two remote
hosts without NATT. The gif tunnel is ipv4 only, host A is ipv4 only,
host B is ipv4/ipv6. I use IPSEC to route traffic between jails on both
hosts, with the jails using
All,
There appears to be an issue with FreeBSD 10.x when using enc device to
filter inbound traffic on the receive path. After searching the mailing
lists, I see two different people reporting the issue ...
https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076900.html
On 10/20/2014 2:47 PM, Andrey V. Elsukov wrote:
On 20.10.2014 20:18, Matthew Grooms wrote:
Lastly, I tried to locate a relevant PR but didn't find anything
concrete. Is this related to the issue? And if so, can it be MFCd?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959
Did you try
On 10/20/2014 2:44 PM, Mark Felder wrote:
On Mon, Oct 20, 2014, at 11:18, Matthew Grooms wrote:
All,
There appears to be an issue with FreeBSD 10.x when using enc device to
filter inbound traffic on the receive path. After searching the mailing
lists, I see two different people reporting
On 10/20/2014 3:50 PM, Andrey V. Elsukov wrote:
On 21.10.2014 00:00, Matthew Grooms wrote:
On 10/20/2014 2:47 PM, Andrey V. Elsukov wrote:
On 20.10.2014 20:18, Matthew Grooms wrote:
Lastly, I tried to locate a relevant PR but didn't find anything
concrete. Is this related to the issue
On 9/15/2014 11:48 AM, Gary Palmer wrote:
On Mon, Sep 15, 2014 at 05:20:05PM +0100, Gary Palmer wrote:
On Mon, Sep 15, 2014 at 08:12:51PM +0400, Lev Serebryakov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 15.09.2014 20:02, Gary Palmer wrote:
If I want to connect to my
Max Laier wrote:
There is clearly something very wrong with how the vswitch works and it's not
really FreeBSD's job to work around these issues. The patch you posted is
rather intrusive and certainly not something we want in the tree. You should
talk to VMWare's support to fix the obvious
Hi all,
I was having problems running carp on VMWare ESX 4 and did a little
investigative work to determine the cause of the problem. There are
several posts on the VMWare forums of other users having the same
difficulty, so I know its not just me :)
In any case, for carp to have a chance
in great detail and, as far as I can tell, have yet to get
this working.
-Matthew
On Jul 19, 2009, at 5:56 PM, Andrew Snow and...@modulus.org wrote:
Matthew Grooms wrote:
I was having problems running carp on VMWare ESX 4 and did a little
investigative work to determine the cause of the problem
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload = sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
I noticed this too. But the
I noticed this too. But the only situation that I could think of where a
valid ISAKMP packet will be smaller than this is a NAT-T keep-alive.
These are handled previously in the code path so I don't think there is
an issue from a functional standpoint.
That's what I also supposed when I
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
partial checksum recalculations.
I've never heard of this term used before with regard to NAT-T ( and
neither has
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
This adds only the kernel portion of the NAT-T support; you must provide
the user-level code from another place.
Note for people who are interested:
user-level code comes from ipsec-tools, as for previous versions of
the NAT-T
All,
I noticed a problem with some software I wrote for FreeBSD using tap
devices. It would appear that you get inconsistent results from ioctl
calls SIOCSIFADDR and SIOCSIFNETMASK when used with tap than when used
with a real Ethernet device. I wrote a quick test program to demonstrate
this
Thanks so much to folks like Bjorn and Yvan who spend the time to do
some tough jobs like dealing with IPsec and being stubborn about
committing things to security tools without very careful audit.
Seconded.
In case you missed it, IPsec is about security, not features. And, in
case you have
Bjoern A. Zeeb wrote:
On Thu, 14 Feb 2008, Matthew Grooms wrote:
Hi,
There is a bug in /usr/src/sys/netipsec/key.c in FreeBSD KAME IPsec
sources.
netipsec/ is not KAME IPsec.
Right, my mistake. FAST IPsec then.
If an spd_delete2 message is submitted for an invalid policy id, the
kernel
All,
There is a bug in /usr/src/sys/netipsec/key.c in FreeBSD KAME IPsec
sources. If an spd_delete2 message is submitted for an invalid policy
id, the kernel crashes. Can someone please commit this trivial patch?
I'm afraid its against 6.2 sources but its also only one line.
Thanks,
Nerius,
This sounds like a DPD timeout. The Cisco VPN client or Cisco gateway is
probably not configured to use NAT-T or you are blocking UDP port 4500.
Using the static-port trick will help in some instances where a client
doesn't support NAT-T, but it also prevents multiple clients behind
On Thu, May 31, 2007 at 08:52:03AM +, Bjoern A. Zeeb wrote:
On Thu, 31 May 2007, VANHULLEBUS Yvan wrote:
[...]
Maybe you could start addressing the things I posted last September?
http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011807.html
You're right: I was sure that this
patents and fast-ipsec
support.
http://lists.freebsd.org/mailman/htdig/freebsd-net/2005-August/007986.html
http://lists.freebsd.org/mailman/htdig/freebsd-net/2006-March/010164.html
* Matthew Grooms [EMAIL PROTECTED] [070511 08:08] wrote:
All,
I understand that FreeBSD is a volunteer
All,
I understand that FreeBSD is a volunteer project, but does anyone
have any information regarding the status of the IPsec NAT Traversal
patches and their inclusion with FeeBSD? I have seen them floating
around this list for a few years now. At one point, there was an
objection that
All,
I have encountered a bug while doing some testing using the ike
daemon that is bundled with the client software that I posted recently
on this list. The daemon is multi threaded and tends to stress the pfkey
interface a bit more than racoon by submitting batches of pfkey messages
All,
I recently released the Shrew Soft Win32 VPN Client 2.0 Beta which
is designed to work with ipsec tools. This software has seen an immense
amount of improvement since the 1.1 release and features a completely
re-worked kernel driver framework, a new direct adapter mode for more
All,
I have been working on ipsec-tools development a bit and am currently
scratching my head over issues related to esp and ipcomp. Since I do
most of my testing with FreeBSD, I tried both the kame ipsec and fast
ipsec support but have had no success to date.
Here are the SPD entries
Matthew Grooms wrote:
All,
With fast ipsec compiled into the kernel, I can see the outbound esp
transport SAD entry increase the current byte count but the ipcomp entry
shows nothing to indicate its use. It seems strange that the kernel will
send acquire messages via PF_KEY as a pre
All,
If anyone is interested in a free IPSEC client that can be used to
connect Win2K/XP hosts to a FreeBSD IPSEC server using ipsec-tools,
please visit the following url ...
http://www.shrew.net/?page=software
The software is intended to offer similar functionality to commercial
All,
If anyone would like to use FreeBSD as a VPN gateway but have the
usual Win2K/XP clients to support, here is a free software product that
may be of interest ...
http://www.shrew.net/download
The VPN Client was designed to work with ipsec-tools + FreeBSD as
the gateway but
IP 10.22.200.21.1228 10.20.10.141.ssh: . ack 2738 win
17024
Sorry in advance for not posting as a reply to the original
message. I don't subscribe to the list. Just wanted to substantiate
Volkers findings.
Hope this helps,
Matthew Grooms
Matthew Grooms wrote:
Volker,
ipfw is enabled. I use purely IPSEC so I would agree that GRE isn't the
problem. This behavior is 100% reproducible for me. If traffic is
forwarded from the host providing the ESP protection or if the
Sorry, this should have read ...
problem. This behavior
Mike Volker,
Try sending different sized pings or other packet size control utils to
really make sure its not MTU related.
Maybe there is an upstream router thats blocking ICMP fragment packets,
have you ever seen them? try forcing the creation of some.
Mike
I am experiencing the same
Is anyone else seeing this issue? I get useless output from tcpdump ( no
header or protocol decode ) but only when I specify a filter on the
command line.
For example ...
[EMAIL PROTECTED] tcpdump -ne -i pflog0 src or dst www.21.com
tcpdump: WARNING: BIOCPROMISC: Network is down
tcpdump:
Pieter de Boer wrote:
Matthew Grooms wrote:
Is anyone else seeing this issue? I get useless output from tcpdump ( no
header or protocol decode ) but only when I specify a filter on the
command line.
listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes
11:33:32.920031
Jung-uk Kim wrote:
On Tuesday 23 August 2005 04:15 pm, Pieter de Boer wrote:
Matthew Grooms wrote:
Is anyone else seeing this issue? I get useless output from
tcpdump ( no header or protocol decode ) but only when I
specify a filter on the command line.
listening on xl0, link-type EN10MB
Not sure if this helps at all, but I did some searching a bit to read
others comments concerning the NAT-T / IPR debate. These two documents
get mentioned repeatedly and would appear to have something to do with
other vendors decision to adopt NAT-T support.
Bjoern A. Zeeb wrote:
On Thu, 4 Aug 2005, Matthew Grooms wrote:
There was also some mention of a third claim but it was hard to find
details on the subject. Lastly, some people voiced concerns regarding
ietf.org - IPR - Search - NAT-T
https://datatracker.ietf.org/public/ipr_detail_show.cgi
Woohoo!!! Thanks!!! I was just checking poking around for this last week
and wondering when someone was going to bring this support to FreeBSD.
For some months now, ipsec-tools is now the official version of
racoon, the KAME's isakmp daemon.
I hope it shows up in ports soon. The racoon port
All,
Has anyone done any extensive testing with the em driver on a 5.4
release amd64 SMP kernel? I have two boxes in a firewall setup that
contain 6 em interfaces each. The public interface on both of them ( em0
) will simply stop transmitting and then start working again after some
time
I know its bad form to respond to myself. Anyhow, please disregard
the previous post. The problem has been resolved.
Thanks,
-Matthew
All,
Has anyone done any extensive testing with the em driver on a 5.4
release amd64 SMP kernel? I have two boxes in a firewall setup that
contain 6
Hmmm,
What we observed on our embedded system is the packet gets sent on all
attached interfaces, with dest IP 255.255.255.255, and a src IP of the
local address that has the default route. If there isn't a default
route, sending to 255.255.255.255 fails with no route to host.
Maybe I am
One more question,
Is there any way to generate a udp broadcast ( all routes
255.255.255.255 ) packet using a standard sendto() without it being
translated into a local network broadcast? Is this just not allowed?
-Matthew
___
[EMAIL PROTECTED]
generate an all-routes
broadcast, they always come out as network directed broadcasts.
Sigh ... If there is not a more conventional way of going about it, I guess
I will just have to generate one using the bpf.
On 7/1/2003, Chuck Swiger [EMAIL PROTECTED] wrote:
Matthew Grooms wrote
for an example of a single bridge.
attach one of the bridge hooks on each site to an ng_socket node that
has made a udp vpn..
see the vpn example for that..
by combining both the bridge and vpn examples you can hook the two
sites together in a bridged manner.
On Tue, 1 Jul 2003, Matthew Grooms wrote
Question,
Is there somthing magic about setting this flag? I wrote a small program
( built on 5.1 ) that uses the bpf to read broadcast packets off a local
private network, forward them to a peer ( over IPSEC ) who in turn drops them
onto its private network ( and visa-versa ). To prevent
Woops,
Please disregard the previous post ... amature programmer at play. Can
an ioctl call return before processing the request? When I started using
seperate variables for the int=1 and int=0 ioctl values, everything works
fine.
-Matthew
Question,
Is there somthing magic about
64 matches
Mail list logo
