Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Dag-Erling Smørgrav wrote: > Yuri Pankov writes: >> There's apparently a bug in VMware Workstation NAT implementation, >> [...] The patch itself is attached. > > Could you please open a differential and add me as reviewer? https://reviews.freebsd.org/D18636 And there's already a PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234426 signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <865zvkpphn@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > I know our code is full of workarounds and theirs probably too. The > > question is should we? IMO no. > > Unfortunately, the world is imperfect and does not care about your > opinion. Correct. I know that too well. > 90% of the hardware we run on deviates from the spec in some > way or another and requires workarounds in the kernel. We even have a > whole system of quirks for disks and USB devices. Libfetch contains > workarounds for buggy HTTP servers. OpenSSH has hundreds of lines of > code devoted to identifying the server and selecting workarounds to > apply. Without those workarounds, FreeBSD would not be a viable piece > of software. Wishing they weren't needed is a waste of time and energy. Well, the patch isn't a hackish as some workounds. This probably doesn't warrant a MK_option however since it changes the default, a mention in the man page should be made. I'm still of the opinion that a management solution would be better, which I'm sure RH is taking. I've been in this business long enough to know that it's a miracle that any of this stuff works. Much of it is held together with bubble gum and string. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Yuri Pankov writes: > There's apparently a bug in VMware Workstation NAT implementation, > [...] The patch itself is attached. Could you please open a differential and add me as reviewer? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. I don't speak for them, but I assure you that both their code and ours are full of workarounds for bugs in third-party software and hardware, and it is ridiculous to claim otherwise. > No. We do like Red Hat does. Advise the customer to use a workaround > until the other vendor fixes their code. With respect, that's not your decision. It's mine. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > I know our code is full of workarounds and theirs probably too. The > question is should we? IMO no. Unfortunately, the world is imperfect and does not care about your opinion. 90% of the hardware we run on deviates from the spec in some way or another and requires workarounds in the kernel. We even have a whole system of quirks for disks and USB devices. Libfetch contains workarounds for buggy HTTP servers. OpenSSH has hundreds of lines of code devoted to identifying the server and selecting workarounds to apply. Without those workarounds, FreeBSD would not be a viable piece of software. Wishing they weren't needed is a waste of time and energy. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <86pntszlae@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. > > I don't speak for them, but I assure you that both their code and ours > are full of workarounds for bugs in third-party software and hardware, > and it is ridiculous to claim otherwise. I know our code is full of workarounds and theirs probably too. The question is should we? IMO no. It's yet another thing that diverges from baseline and that adds support costs (well, ok we're not a for profit business but you get the idea). Sure, you may be the person to support ssh here but divergence from baseline is usually not a good thing. When I was developer as a living management would rule against this kind of thing. Their rationale at the time was, "what if you're away?" At the time I'd curse at them but thinking about it years later, they did have a point. > > > No. We do like Red Hat does. Advise the customer to use a workaround > > until the other vendor fixes their code. > > With respect, that's not your decision. It's mine. With respect, I disagree with your decision then. Please don't make that decision because your going to show me though. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert writes: > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. It's something we do *all the time*. Otherwise we'd just be a toy OS that hobbyists played with in the weekends on an old spare machine they keep in a basement closet. > If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. Then it's useless. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <861s681ypd@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg rav?= w rites: > Cy Schubert writes: > > Add it to ssh_config or sshd_config if one must but have VMware fix > > their bugs. Putting workarounds in our O/S to work around a bug in some > > other vendor's virtualization is something I don't support. > > It's something we do *all the time*. Otherwise we'd just be a toy OS > that hobbyists played with in the weekends on an old spare machine they > keep in a basement closet. Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then. > > > If we must > > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > > in src.conf. > > Then it's useless. No. We do like Red Hat does. Advise the customer to use a workaround until the other vendor fixes their code. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <82004750-097a-47e5-9981-86b4b7a5f...@gmail.com>, Enji Cooper writes : > > On Dec 22, 2018, at 1:03 PM, Cy Schubert = > wrote: > > =E2=80=A6 > > > Regarding the Red Hat bugzilla bug, looks like they're doing the right > > thing by reaching out to VMware. This should be our position as well. > > Add it to ssh_config or sshd_config if one must but have VMware fix > > their bugs. Putting workarounds in our O/S to work around a bug in = > some > > other vendor's virtualization is something I don't support. If we must > > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable = > it > > in src.conf. > > This is the reason why I CCed mp@ :).. Mark works for VMware (I worked = > with him a bit when I was at Isilon). > > =E2=80=A6 > > > We, FreeBSD, should try to open a ticket or reach out to VMware to add > > a +1 to the issue that RH has already opened. This is the right thing > > to do. In this case we should consider ourselves an O/S vendor too, > > which BTW we are. > > Yes, but unless there=E2=80=99s a champion internal to the project = > driving this, it=E2=80=99s up to individual users to drive the bug = > report/fix. If, however, there were regular regression tests run with = > VMware (and this can be done with pyvmomi/paramiko, etc), then we the = > project could provide this guarantee to VMware and vice versa if VMware = > invested the time in making this so--which I thought they did with = > 10.x=E2=80=A6 but if they don=E2=80=99t have an easy way to verify = > changes, there=E2=80=99s a bit of a chicken and egg problem. I'm suggesting we do. Regression tests might require that FreeBSD have a VMware cluster of one or preferably two machines somewhere. That is if VMware is willing to "help" out. The reason I suggest a cluster of two is vmotion can negatively affect some applications (Oracle RAC comes to mind). It would be interesting to find out how FreeBSD and apps running on FreeBSD react to being vmotioned from one ESXi host to another. Testing vCPU and vRAM hot add are other items that should be in our test suite. How well would FreeBSD work with vNUMA? > > > BTW the 2018-11-08 entry in the RH bug talks about adding the > > workaround to sshd_config. > > =E2=80=A6 which is what I did instead of making the code change. Does this suggest that sshd on servers running under VMware are also affected, i.e. ssh session from a computer not running on VMware such as from real hardware or a from PuTTY session o a PC to sshd on a VM? > > Thanks so very much for the patch and (more importantly) for the = > discussion/solution Yuri!! I really appreciate your unblocking me. Yes, thank you Yuri for pointing out the problem and providing a solution. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 22, 2018, at 1:03 PM, Cy Schubert wrote: … > Regarding the Red Hat bugzilla bug, looks like they're doing the right > thing by reaching out to VMware. This should be our position as well. > Add it to ssh_config or sshd_config if one must but have VMware fix > their bugs. Putting workarounds in our O/S to work around a bug in some > other vendor's virtualization is something I don't support. If we must > add the #ifdefs to our ssh, then add an UPDATING entry to say that to > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it > in src.conf. This is the reason why I CCed mp@ :).. Mark works for VMware (I worked with him a bit when I was at Isilon). … > We, FreeBSD, should try to open a ticket or reach out to VMware to add > a +1 to the issue that RH has already opened. This is the right thing > to do. In this case we should consider ourselves an O/S vendor too, > which BTW we are. Yes, but unless there’s a champion internal to the project driving this, it’s up to individual users to drive the bug report/fix. If, however, there were regular regression tests run with VMware (and this can be done with pyvmomi/paramiko, etc), then we the project could provide this guarantee to VMware and vice versa if VMware invested the time in making this so--which I thought they did with 10.x… but if they don’t have an easy way to verify changes, there’s a bit of a chicken and egg problem. > BTW the 2018-11-08 entry in the RH bug talks about adding the > workaround to sshd_config. … which is what I did instead of making the code change. Thanks so very much for the patch and (more importantly) for the discussion/solution Yuri!! I really appreciate your unblocking me. Cheers, -Enji signature.asc Description: Message signed with OpenPGP
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>, Yuri Pankov write s: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --e7sW91Qf9WxzTaujtGEdAimN5k2EtpJ6Q > Content-Type: multipart/mixed; boundary="3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm"; > protected-headers="v1" > From: Yuri Pankov > To: Cy Schubert > Cc: Mark Peek , Enji Cooper , > Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= > , freebsd-current > Message-ID: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net> > Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 > changes > References: <20181027.wbmkrgwj050...@slippy.cwsent.com> > In-Reply-To: <20181027.wbmkrgwj050...@slippy.cwsent.com> > > --3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm > Content-Type: text/plain; charset=utf-8 > Content-Language: en-US > Content-Transfer-Encoding: quoted-printable > > Cy Schubert wrote: > > In message , Yuri=20 > > Pankov write > > s: > >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH > >> Content-Type: multipart/mixed; boundary=3D"c7yUHUJpZYpJqOrOWLAb4sE3Rmh= > 2alrdi"; > >> protected-headers=3D"v1" > >> From: Yuri Pankov > >> To: Cy Schubert > >> Cc: Mark Peek , Enji Cooper , > >> Warner Losh , =3D?UTF-8?Q?Dag-Erling_Sm=3Dc3=3Db8rgra= > v?=3D > >> , freebsd-current > >> Message-ID: > >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8= > p1 > >> changes > >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> > >> > >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi > >> Content-Type: text/plain; charset=3Dutf-8 > >> Content-Language: en-US > >> Content-Transfer-Encoding: quoted-printable > >> > >> Cy Schubert wrote: > >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=3D= > 20 > >>> Pankov write > >>> s: > >>>> Yuri Pankov wrote: > >>>>> In-Reply-To: ai=3D > >> > >>> l.gmail. > >>>>> com> > >>>>> Mark Peek wrote: > >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > > >>> wro=3D3D > >>>>> te: > >>>>>> =3D3D20 > >>>>>>> > >>>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote= > : > >>>>>>>> > >>>>>>>> Mark Peek wrote: > >>>>>>>>> Thanks for the cc:. I forwarded the original report on to an=3D= > 20 > >>> interna=3D3D > >>>>> l > >>>>>>>>> VMware desktop product contact. > >>>>>>>> > >>>>>>>> Thank you. > >>>>>>>> > >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=3D= > 20 > >>> saw > >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=3D20 > >>> Workstation 15 > >>>>>>>>> (latest). > >>>>>>>> > >>>>>>>> Running the latest available for download: 15.0.2 build-10952284= > =2E > >>>>>>> > >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=3D= > 20 > >>> wasn=3D3DE2=3D3D > >>>>> =3D3D80=3D3D99t > >>>>>>> affecting me on 10.x. I didn=3D3DE2=3D3D80=3D3D99t install 11.0.0= > , so I=3D20 > >>> don=3D3DE2=3D3D80=3D3D99=3D3D > >>>>> t know if it > >>>>>>> affects that version... > >>>>>>> > >>>>>>> Thanks so much! > >>>>>>> > >>>>>>> -Enji > >>>>>> =3D3D20 > >>>>>> =3D3D20 > >>>>>> BTW, there appears to be a workaround here using -o=3D20 > >>> 'IPQoS=3D3D3Dthroughput=3D3D > >>>>> ' > >>>>>> (untested by me). I've seen the issue forwarded internally but no=3D= > 20 > >>> furth=3D3D > >>>>> er > >>>>>> discussions yet. > >>>>>> =3D3D20 > >>>>>> https://communities.vmware.com/thread/590825 > >>>> > >>>> Yes, tha
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message , Yuri > Pankov write > s: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH >> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi"; >> protected-headers="v1" >> From: Yuri Pankov >> To: Cy Schubert >> Cc: Mark Peek , Enji Cooper , >> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= >> , freebsd-current >> Message-ID: >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 >> changes >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com> >> >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi >> Content-Type: text/plain; charset=utf-8 >> Content-Language: en-US >> Content-Transfer-Encoding: quoted-printable >> >> Cy Schubert wrote: >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20 >>> Pankov write >>> s: >>>> Yuri Pankov wrote: >>>>> In-Reply-To: > >>> l.gmail. >>>>> com> >>>>> Mark Peek wrote: >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper >>> wro=3D >>>>> te: >>>>>> =3D20 >>>>>>> >>>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>>>>>>> >>>>>>>> Mark Peek wrote: >>>>>>>>> Thanks for the cc:. I forwarded the original report on to an=20 >>> interna=3D >>>>> l >>>>>>>>> VMware desktop product contact. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=20 >>> saw >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=20 >>> Workstation 15 >>>>>>>>> (latest). >>>>>>>> >>>>>>>> Running the latest available for download: 15.0.2 build-10952284. >>>>>>> >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20 >>> wasn=3DE2=3D >>>>> =3D80=3D99t >>>>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20 >>> don=3DE2=3D80=3D99=3D >>>>> t know if it >>>>>>> affects that version... >>>>>>> >>>>>>> Thanks so much! >>>>>>> >>>>>>> -Enji >>>>>> =3D20 >>>>>> =3D20 >>>>>> BTW, there appears to be a workaround here using -o=20 >>> 'IPQoS=3D3Dthroughput=3D >>>>> ' >>>>>> (untested by me). I've seen the issue forwarded internally but no=20 >>> furth=3D >>>>> er >>>>>> discussions yet. >>>>>> =3D20 >>>>>> https://communities.vmware.com/thread/590825 >>>> >>>> Yes, that's exactly what the patch attached to original message does i= >> f >>>> we are running as a VMware guest. The workaround is known and it work= >> s, >>>> but it's not immediately clear and I just wanted it to be the default >>>> for the time being. >>> =20 >>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20 >>> intended? >> >> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can >> be ripped out easily when no longer needed, and yes, it's enabled >> unconditionally for now. And the check itself is if 'kern.vm_guest' >> reports 'vmware'. > > It doesn't look that conditional to me. Indeed, and that's what I said exactly :-) The added code is enabled unconditionally, and the added code also has a check for vmware guest. The ifdefs are there only to show that this is local addition, nothing else. I'm not saying it needs to be done this way, this is just something I did quickly after installing yet another VM and forgetting to modify my ~/.ssh/config to include the workaround. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message , Yuri
Pankov write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi";
> protected-headers="v1"
> From: Yuri Pankov
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID:
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
> changes
> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>
> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Cy Schubert wrote:
> > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20
> > Pankov write
> > s:
> >> Yuri Pankov wrote:
> >>> In-Reply-To:
> > l.gmail.
> >>> com>
> >>> Mark Peek wrote:
> >>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper
> > wro=3D
> >>> te:
> >>>> =3D20
> >>>>>
> >>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
> >>>>>>
> >>>>>> Mark Peek wrote:
> >>>>>>> Thanks for the cc:. I forwarded the original report on to an=20
> > interna=3D
> >>> l
> >>>>>>> VMware desktop product contact.
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>>> What version of Workstation or Fusion is this occurring on? I=20
> > saw
> >>>>>>> Workstation 14 mentioned but curious if it occurs on=20
> > Workstation 15
> >>>>>>> (latest).
> >>>>>>
> >>>>>> Running the latest available for download: 15.0.2 build-10952284.
> >>>>>
> >>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20
> > wasn=3DE2=3D
> >>> =3D80=3D99t
> >>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20
> > don=3DE2=3D80=3D99=3D
> >>> t know if it
> >>>>> affects that version...
> >>>>>
> >>>>> Thanks so much!
> >>>>>
> >>>>> -Enji
> >>>> =3D20
> >>>> =3D20
> >>>> BTW, there appears to be a workaround here using -o=20
> > 'IPQoS=3D3Dthroughput=3D
> >>> '
> >>>> (untested by me). I've seen the issue forwarded internally but no=20
> > furth=3D
> >>> er
> >>>> discussions yet.
> >>>> =3D20
> >>>> https://communities.vmware.com/thread/590825
> >>
> >> Yes, that's exactly what the patch attached to original message does i=
> f
> >> we are running as a VMware guest. The workaround is known and it work=
> s,
> >> but it's not immediately clear and I just wanted it to be the default
> >> for the time being.
> >=20
> > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20
> > intended?
>
> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
> be ripped out easily when no longer needed, and yes, it's enabled
> unconditionally for now. And the check itself is if 'kern.vm_guest'
> reports 'vmware'.
It doesn't look that conditional to me.
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Cy Schubert wrote: > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri > Pankov write > s: >> Yuri Pankov wrote: >>> In-Reply-To: l.gmail. >>> com> >>> Mark Peek wrote: On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wro= >>> te: =20 > >> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >> >> Mark Peek wrote: >>> Thanks for the cc:. I forwarded the original report on to an > interna= >>> l >>> VMware desktop product contact. >> >> Thank you. >> >>> What version of Workstation or Fusion is this occurring on? I > saw >>> Workstation 14 mentioned but curious if it occurs on > Workstation 15 >>> (latest). >> >> Running the latest available for download: 15.0.2 build-10952284. > > This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it > wasn=E2= >>> =80=99t > affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I > don=E2=80=99= >>> t know if it > affects that version... > > Thanks so much! > > -Enji =20 =20 BTW, there appears to be a workaround here using -o > 'IPQoS=3Dthroughput= >>> ' (untested by me). I've seen the issue forwarded internally but no > furth= >>> er discussions yet. =20 https://communities.vmware.com/thread/590825 >> >> Yes, that's exactly what the patch attached to original message does if >> we are running as a VMware guest. The workaround is known and it works, >> but it's not immediately clear and I just wanted it to be the default >> for the time being. > > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this > intended? It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can be ripped out easily when no longer needed, and yes, it's enabled unconditionally for now. And the check itself is if 'kern.vm_guest' reports 'vmware'. > Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and > Windows) running on VMware clusters with NSX network (with plans to > totally virtualize the network), we've noticed other network > quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris > <--> Linux. I'm not surprised that this regression also exists. > > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri Pankov write s: > Yuri Pankov wrote: >> In-Reply-To: > com> >> Mark Peek wrote: >> > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wro= >> te: >> >=20 >> >> >> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >> >>> >> >>> Mark Peek wrote: >> Thanks for the cc:. I forwarded the original report on to an interna= >> l >> VMware desktop product contact. >> >>> >> >>> Thank you. >> >>> >> What version of Workstation or Fusion is this occurring on? I saw >> Workstation 14 mentioned but curious if it occurs on Workstation 15 >> (latest). >> >>> >> >>> Running the latest available for download: 15.0.2 build-10952284. >> >> >> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn=E2= >> =80=99t >> >> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I don=E2=80=99= >> t know if it >> >> affects that version... >> >> >> >> Thanks so much! >> >> >> >> -Enji >> >=20 >> >=20 >> > BTW, there appears to be a workaround here using -o 'IPQoS=3Dthroughput= >> ' >> > (untested by me). I've seen the issue forwarded internally but no furth= >> er >> > discussions yet. >> >=20 >> > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this intended? Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and Windows) running on VMware clusters with NSX network (with plans to totally virtualize the network), we've noticed other network quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris <--> Linux. I'm not surprised that this regression also exists. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
On Sat, Dec 22, 2018, 11:03 AM Yuri Pankov Mark Peek wrote: > > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper > wrote: > > > >> > >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > >>> > >>> Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. > >>> > >>> Thank you. > >>> > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). > >>> > >>> Running the latest available for download: 15.0.2 build-10952284. > >> > >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t > >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it > >> affects that version... > >> > >> Thanks so much! > >> > >> -Enji > > > > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > > (untested by me). I've seen the issue forwarded internally but no further > > discussions yet. > > > > https://communities.vmware.com/thread/590825 > > Yes, that's exactly what the patch attached to original message does if > we are running as a VMware guest. The workaround is known and it works, > but it's not immediately clear and I just wanted it to be the default > for the time being. > Fixes my world... Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > >> >>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: >>> >>> Mark Peek wrote: Thanks for the cc:. I forwarded the original report on to an internal VMware desktop product contact. >>> >>> Thank you. >>> What version of Workstation or Fusion is this occurring on? I saw Workstation 14 mentioned but curious if it occurs on Workstation 15 (latest). >>> >>> Running the latest available for download: 15.0.2 build-10952284. >> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it >> affects that version... >> >> Thanks so much! >> >> -Enji > > > BTW, there appears to be a workaround here using -o 'IPQoS=throughput' > (untested by me). I've seen the issue forwarded internally but no further > discussions yet. > > https://communities.vmware.com/thread/590825 Yes, that's exactly what the patch attached to original message does if we are running as a VMware guest. The workaround is known and it works, but it's not immediately clear and I just wanted it to be the default for the time being. signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote: > > > On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > > > > Mark Peek wrote: > >> Thanks for the cc:. I forwarded the original report on to an internal > >> VMware desktop product contact. > > > > Thank you. > > > >> What version of Workstation or Fusion is this occurring on? I saw > >> Workstation 14 mentioned but curious if it occurs on Workstation 15 > >> (latest). > > > > Running the latest available for download: 15.0.2 build-10952284. > > This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t > affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it > affects that version... > > Thanks so much! > > -Enji BTW, there appears to be a workaround here using -o 'IPQoS=throughput' (untested by me). I've seen the issue forwarded internally but no further discussions yet. https://communities.vmware.com/thread/590825 Mark ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 17:48, Yuri Pankov wrote: > > Mark Peek wrote: >> Thanks for the cc:. I forwarded the original report on to an internal >> VMware desktop product contact. > > Thank you. > >> What version of Workstation or Fusion is this occurring on? I saw >> Workstation 14 mentioned but curious if it occurs on Workstation 15 >> (latest). > > Running the latest available for download: 15.0.2 build-10952284. This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it affects that version... Thanks so much! -Enji ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Mark Peek wrote: > Thanks for the cc:. I forwarded the original report on to an internal > VMware desktop product contact. Thank you. > What version of Workstation or Fusion is this occurring on? I saw > Workstation 14 mentioned but curious if it occurs on Workstation 15 > (latest). Running the latest available for download: 15.0.2 build-10952284. > On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > >> I've been hit by this as well. At least two others on IRC have had the >> same issue. >> >> Warner >> >> On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: >> >>> >>>> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: >>>> >>>> Hi, >>>> >>>> There's apparently a bug in VMware Workstation NAT implementation, made >>>> visible by the change to default values of IPQoS in OpenSSH 7.8p1, >>>> making all ssh connections from the guest behind the NAT to fail with >>>> obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: >>>> Broken pipe". >>>> >>>> I wonder if we could integrate the attached patch (or some smarter >>>> version of it) for the time being as the bug affects several major WS >>>> releases, and it's not immediately clear where the problem is. >>>> >>>> The change itself: >>>> >>>> >>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 >>>> >>>> The bug reports (some of them): >>>> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1624437 >>>> https://communities.vmware.com/message/2803219#2803219 >>>> >>>> The patch itself is attached. >>>> >>> >>> Cool… yeah… I’ve been running into this issue for a while with >>> VMware Fusion 11.0.1. >>> I CCed mp@ for visibility. >>> Thanks! >>> -Enji >>> >> > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > signature.asc Description: OpenPGP digital signature
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Thanks for the cc:. I forwarded the original report on to an internal VMware desktop product contact. What version of Workstation or Fusion is this occurring on? I saw Workstation 14 mentioned but curious if it occurs on Workstation 15 (latest). Mark On Fri, Dec 21, 2018 at 4:19 PM Warner Losh wrote: > I've been hit by this as well. At least two others on IRC have had the > same issue. > > Warner > > On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > >> >> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: >> > >> > Hi, >> > >> > There's apparently a bug in VMware Workstation NAT implementation, made >> > visible by the change to default values of IPQoS in OpenSSH 7.8p1, >> > making all ssh connections from the guest behind the NAT to fail with >> > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: >> > Broken pipe". >> > >> > I wonder if we could integrate the attached patch (or some smarter >> > version of it) for the time being as the bug affects several major WS >> > releases, and it's not immediately clear where the problem is. >> > >> > The change itself: >> > >> > >> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 >> > >> > The bug reports (some of them): >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 >> > https://communities.vmware.com/message/2803219#2803219 >> > >> > The patch itself is attached. >> > >> >> Cool… yeah… I’ve been running into this issue for a while with >> VMware Fusion 11.0.1. >> I CCed mp@ for visibility. >> Thanks! >> -Enji >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
I've been hit by this as well. At least two others on IRC have had the same issue. Warner On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote: > > > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > > > Hi, > > > > There's apparently a bug in VMware Workstation NAT implementation, made > > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > > making all ssh connections from the guest behind the NAT to fail with > > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > > Broken pipe". > > > > I wonder if we could integrate the attached patch (or some smarter > > version of it) for the time being as the bug affects several major WS > > releases, and it's not immediately clear where the problem is. > > > > The change itself: > > > > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > > > The bug reports (some of them): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > > https://communities.vmware.com/message/2803219#2803219 > > > > The patch itself is attached. > > > > Cool… yeah… I’ve been running into this issue for a while with > VMware Fusion 11.0.1. > I CCed mp@ for visibility. > Thanks! > -Enji > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote: > > Hi, > > There's apparently a bug in VMware Workstation NAT implementation, made > visible by the change to default values of IPQoS in OpenSSH 7.8p1, > making all ssh connections from the guest behind the NAT to fail with > obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22: > Broken pipe". > > I wonder if we could integrate the attached patch (or some smarter > version of it) for the time being as the bug affects several major WS > releases, and it's not immediately clear where the problem is. > > The change itself: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284 > > The bug reports (some of them): > > https://bugzilla.redhat.com/show_bug.cgi?id=1624437 > https://communities.vmware.com/message/2803219#2803219 > > The patch itself is attached. > Cool… yeah… I’ve been running into this issue for a while with VMware Fusion 11.0.1. I CCed mp@ for visibility. Thanks! -Enji signature.asc Description: Message signed with OpenPGP
workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
Broken pipe".
I wonder if we could integrate the attached patch (or some smarter
version of it) for the time being as the bug affects several major WS
releases, and it's not immediately clear where the problem is.
The change itself:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
The bug reports (some of them):
https://bugzilla.redhat.com/show_bug.cgi?id=1624437
https://communities.vmware.com/message/2803219#2803219
The patch itself is attached.
diff --git a/crypto/openssh/readconf.c b/crypto/openssh/readconf.c
index f97a6ac72a95..9ed6902a0f46 100644
--- a/crypto/openssh/readconf.c
+++ b/crypto/openssh/readconf.c
@@ -16,6 +16,9 @@
__RCSID("$FreeBSD$");
#include
+#ifdef VMWARE_GUEST_WORKAROUND
+#include
+#endif
#include
#include
#include
@@ -1954,6 +1957,15 @@ fill_default_options(Options * options)
{
char *all_cipher, *all_mac, *all_kex, *all_key;
int r;
+#ifdef VMWARE_GUEST_WORKAROUND
+ char scval[7]; /* "vmware\0" */
+ size_t scsiz = sizeof(scval);
+ int vmwguest = 0;
+
+ if (sysctlbyname("kern.vm_guest", scval, , NULL, 0) == 0 &&
+ strcmp(scval, "vmware") == 0)
+ vmwguest = 1;
+#endif
if (options->forward_agent == -1)
options->forward_agent = 0;
@@ -2088,8 +2100,18 @@ fill_default_options(Options * options)
if (options->visual_host_key == -1)
options->visual_host_key = 0;
if (options->ip_qos_interactive == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_interactive = IPTOS_LOWDELAY;
+ else
+#endif
options->ip_qos_interactive = IPTOS_DSCP_AF21;
if (options->ip_qos_bulk == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+ if (vmwguest)
+ options->ip_qos_bulk = IPTOS_THROUGHPUT;
+ else
+#endif
options->ip_qos_bulk = IPTOS_DSCP_CS1;
if (options->request_tty == -1)
options->request_tty = REQUEST_TTY_AUTO;
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+= crypto
CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
.endif
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
.include
.PATH: ${SSHDIR}
signature.asc
Description: OpenPGP digital signature
12.0-RC3 vnet jail with pf firewall/NAT not working
Have gateway host, (ie; host that is connected directly to the public internet.) running a vnet jail that has pf firewall running inside of it. When I start the vnet jail I see a few dhclient tasks auto start for vge0 which is the interface added as member to the bridge. I take this to mean that the vnet jails external network is configured correctly. Can not ping 8.8.8.8 from the vnet jails console. I can see the pf rules are loaded. But the pf log shows no traffic at all. Think problem is with the nat rule syntax or the nat function of pf is non-functional. Can not reach the public internet using this nat rule nat pass on epair2b inet from 10.0.20.10 to any -> xx.xx.xx.xx 10.0.20.10 is ip address assigned to the vnet jail xx.xx.xx.xx is the ip address assigned to the host by the isp. Also tried this with no joy nat pass on epair2b inet from 10.0.20.10 to any -> epair2b Anyone been able to get pf NAT to work in a live vnet jail in this manner? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT)
On 13.07.2018 14:10, Lev Serebryakov wrote:
> when system is unresponsive I see this in `top -SH`
>
> 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
> 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
>
> And it is new to me.
Oh, this MoBo has (and uses) two em0 adapters:
em0@pci0:2:0:0: class=0x02 card=0x202c8086 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
em1@pci0:1:0:0: class=0x02 card=0x202c8086 chip=0x10d38086 rev=0x00
hdr=0x00
vendor = 'Intel Corporation'
device = '82574L Gigabit Network Connection'
class = network
subclass = ethernet
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
[REGRESSION] Fresh CURRENT consume much more CPU on network traffic (vlans + routing + ipfw with NAT)
I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs
CURRENT for very long time (from 11-CURRENT times), and recently it
start to consume much more CPU on same traffic — to the point when it
becomes unresponsive in shell (via ssh, not local console).
I have rather complex ipfw ruleset, but this ruleset is the same for
many years.
Revisions before r333989 worked normally, I never seen any problem with
shell, no matter how much traffic is processed
Revision r334649 with same configuration, same firewall ruleset, etc.,
becomes completely unresponsive under network load (pure transit traffic).
when system is unresponsive I see this in `top -SH`
100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
And it is new to me.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
Am Wed, 27 Sep 2017 14:17:14 +0200 Damjan Jovanovic <damjan@gmail.com> schrieb: > On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann <o.hartm...@walstatt.org> > wrote: > > > On Tue, 26 Sep 2017 16:26:51 +0200 > > Damjan Jovanovic <damjan@gmail.com> wrote: > > > > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartm...@walstatt.org> > > > wrote: > > > > > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > > > Damjan Jovanovic <damjan@gmail.com> wrote: > > > > > > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann < > > ohartm...@walstatt.org> > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) > > appliance, I > > > > ran > > > > > > into > > > > > > several problems. My questions might have a "noobish" character, > > so my > > > > > > apology, > > > > > > my experiences with IPFW are not as thorough as they should be. > > > > > > > > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > > > > > > > > > - port net/asterisk13 is supposed to build only on armv6, is > > aarch64 > > > > about > > > > > > coming soon also supported? > > > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX > > platform > > > > > > (assumed > > > > > > having 2 GB of RAM)? > > > > > > > > > > > > My main concern is about IPFW (we do not use PF for some reasons, I > > > > > > > > > > have to > > > > > > stay with IPFW). > > > > > > > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and > > not > > > > yet > > > > > > IPv6. > > > > > > The FreeBSD system acting as a router is supposed to have a jail > > soon > > > > > > containing the Asterisk 13 IP PBX (at the moment running on the > > main > > > > > > system). > > > > > > To provide access to the VoIP infrastructure inside/behind the > > > > router/NAT > > > > > > system, the in-kernel NAT facility of FreeBSD is forwarding the > > > > relevant > > > > > > UPD/TCP ports for VoIP to its destination network, and here I have > > a > > > > > > problem to > > > > > > solve. > > > > > > > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other > > > > > > > > > > ports, > > > > > > it > > > > > > is a mess and pain in the arse to forward a whole range, say > > 11000/udp > > > > - > > > > > > 35000/udp, which is a range one of my providers is sending RTP on. > > A > > > > second > > > > > > provider uses another range for RTP, starting at 5000/udp. So, the > > > > logical > > > > > > consequence would be a union set up UDP range to forward, which > > exapnds > > > > > > then > > > > > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > > > > > > > > > One of the most disturbing and well known problems is that due to > > the > > > > > > stateful > > > > > > firewall the RTP session very often is half duplex - it seems one > > > > direction > > > > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > > > > search > > > > > > the > > > > > > net, I always get informed this is a typical problem and solutions > > are > > > > > > provided by so called ALGs - since SIP protocol's SDP indicates > > within > > > > the > > > > > > payload of the packets on which UDP ports both ends wish to > > establish > > > > their > > > > > > RTP session, it would be "easy" to pinhole the IPFW on exactly > > those > > > > ports > > > > > > for > > > > > > a theoretical large number of session
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Wed, Sep 27, 2017 at 1:16 PM, O. Hartmann <o.hartm...@walstatt.org> wrote: > On Tue, 26 Sep 2017 16:26:51 +0200 > Damjan Jovanovic <damjan@gmail.com> wrote: > > > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartm...@walstatt.org> > > wrote: > > > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > > Damjan Jovanovic <damjan@gmail.com> wrote: > > > > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann < > ohartm...@walstatt.org> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) > appliance, I > > > ran > > > > > into > > > > > several problems. My questions might have a "noobish" character, > so my > > > > > apology, > > > > > my experiences with IPFW are not as thorough as they should be. > > > > > > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > > > > > > > - port net/asterisk13 is supposed to build only on armv6, is > aarch64 > > > about > > > > > coming soon also supported? > > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX > platform > > > > > (assumed > > > > > having 2 GB of RAM)? > > > > > > > > > > My main concern is about IPFW (we do not use PF for some reasons, I > > > have to > > > > > stay with IPFW). > > > > > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and > not > > > yet > > > > > IPv6. > > > > > The FreeBSD system acting as a router is supposed to have a jail > soon > > > > > containing the Asterisk 13 IP PBX (at the moment running on the > main > > > > > system). > > > > > To provide access to the VoIP infrastructure inside/behind the > > > router/NAT > > > > > system, the in-kernel NAT facility of FreeBSD is forwarding the > > > relevant > > > > > UPD/TCP ports for VoIP to its destination network, and here I have > a > > > > > problem to > > > > > solve. > > > > > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other > > > ports, > > > > > it > > > > > is a mess and pain in the arse to forward a whole range, say > 11000/udp > > > - > > > > > 35000/udp, which is a range one of my providers is sending RTP on. > A > > > second > > > > > provider uses another range for RTP, starting at 5000/udp. So, the > > > logical > > > > > consequence would be a union set up UDP range to forward, which > exapnds > > > > > then > > > > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > > > > > > > One of the most disturbing and well known problems is that due to > the > > > > > stateful > > > > > firewall the RTP session very often is half duplex - it seems one > > > direction > > > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > > > search > > > > > the > > > > > net, I always get informed this is a typical problem and solutions > are > > > > > provided by so called ALGs - since SIP protocol's SDP indicates > within > > > the > > > > > payload of the packets on which UDP ports both ends wish to > establish > > > their > > > > > RTP session, it would be "easy" to pinhole the IPFW on exactly > those > > > ports > > > > > for > > > > > a theoretical large number of sessions, if IPFW could "divert" > those > > > > > packets > > > > > to an instance inspecting SDP (or whatever is used for the RTP port > > > > > indication, I'm new to that, sorry for the terminology) and then > > > pinholing > > > > > the > > > > > NAT/IPFW for exactly this purpose without the forwarding mess. I > came > > > along > > > > > netgraph() while searching for hints and hooks, but it seems a > complete > > > > > Linux > > > > > domain, when it somes to appliances like VoIP/IP PBX. > > > > > > > > > > Either, the problem is that trivial on FreeBSD, so no further
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, Sep 26, 2017 at 11:27 AM, Guido Falsi <madpi...@freebsd.org> wrote: > On 09/26/2017 10:35, O. Hartmann wrote: > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > search the > > net, I always get informed this is a typical problem and solutions are > > provided by so called ALGs - since SIP protocol's SDP indicates within > the > > This would require coding it in IPFW, and the load on the firewall could > be significant. > > It could be done in userland maybe, leveraging divert(4) and having a > daemon listening there and doing the extra work, but this would be quite > expensive. Depending on your call volume the load could be too much for > your firewall. > > SIP headers like Proxy-Authorization need to send a cryptographic quality hash of data that includes the password and the SDP when qop=auth-int, and the ALG needs to change the IP address and port in the SDP, which changes this hash. The ALG would have to know your password to calculate the new hash. A SIP ALG can thus only work with the weaker qop=auth protection, which doesn't hash the SDP and is thus less secure (MITM attacks can capture/modify RTP in transit), and even then it would have to be careful not to change the SIP headers which are included in the hash. Since it is the provider that chooses the allowed qop, a general SIP ALG is impossible unless the ALG knows the password. Linux has a SIP ALG in iptables, and it's full of problems and best disabled. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, 26 Sep 2017 16:26:51 +0200 Damjan Jovanovic <damjan@gmail.com> wrote: > On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartm...@walstatt.org> > wrote: > > > On Tue, 26 Sep 2017 11:00:45 +0200 > > Damjan Jovanovic <damjan@gmail.com> wrote: > > > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartm...@walstatt.org> > > > wrote: > > > > > > > Hello, > > > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I > > ran > > > > into > > > > several problems. My questions might have a "noobish" character, so my > > > > apology, > > > > my experiences with IPFW are not as thorough as they should be. > > > > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 > > about > > > > coming soon also supported? > > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > > > (assumed > > > > having 2 GB of RAM)? > > > > > > > > My main concern is about IPFW (we do not use PF for some reasons, I > > have to > > > > stay with IPFW). > > > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not > > yet > > > > IPv6. > > > > The FreeBSD system acting as a router is supposed to have a jail soon > > > > containing the Asterisk 13 IP PBX (at the moment running on the main > > > > system). > > > > To provide access to the VoIP infrastructure inside/behind the > > router/NAT > > > > system, the in-kernel NAT facility of FreeBSD is forwarding the > > relevant > > > > UPD/TCP ports for VoIP to its destination network, and here I have a > > > > problem to > > > > solve. > > > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other > > ports, > > > > it > > > > is a mess and pain in the arse to forward a whole range, say 11000/udp > > - > > > > 35000/udp, which is a range one of my providers is sending RTP on. A > > second > > > > provider uses another range for RTP, starting at 5000/udp. So, the > > logical > > > > consequence would be a union set up UDP range to forward, which exapnds > > > > then > > > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > > > > > One of the most disturbing and well known problems is that due to the > > > > stateful > > > > firewall the RTP session very often is half duplex - it seems one > > direction > > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > > search > > > > the > > > > net, I always get informed this is a typical problem and solutions are > > > > provided by so called ALGs - since SIP protocol's SDP indicates within > > the > > > > payload of the packets on which UDP ports both ends wish to establish > > their > > > > RTP session, it would be "easy" to pinhole the IPFW on exactly those > > ports > > > > for > > > > a theoretical large number of sessions, if IPFW could "divert" those > > > > packets > > > > to an instance inspecting SDP (or whatever is used for the RTP port > > > > indication, I'm new to that, sorry for the terminology) and then > > pinholing > > > > the > > > > NAT/IPFW for exactly this purpose without the forwarding mess. I came > > along > > > > netgraph() while searching for hints and hooks, but it seems a complete > > > > Linux > > > > domain, when it somes to appliances like VoIP/IP PBX. > > > > > > > > Either, the problem is that trivial on FreeBSD, so no further > > mentioning is > > > > necessary (which would explain the vast emptyness of explanations, > > hints > > > > and > > > > so on) or FreeBSD is a complete wasteland on this subject - which I > > also > > > > suspect, since pfSense and OPNsense must have come along with such > > problems > > > > and I simply do not know or recognise the software used for those > > purposes. > > > > > > > > So, if someone enlightened in this matte
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
Sorry the top posting but Before anything else I need to state a few points. First this post is getting quite VoIP and asterisk specific, so please direct any further replies to me at my email. We're off subject on this list. Also before giving specific answers I need to clarify a few details about SIP/SDP and RTP, since, from your message it looks like you have some misconceptions about some details. In specific how RTP connection endpoints are negotiated and how the connections actually happen after that. (I'll make a general description to be sure everything is clear) SIP accepts connections on only one port (UDP usually but TCP is also supported), 5060 by default, but can be changed. This IP:port combination is what is registered with people wanting to call you, be it SIP REGISTER on a provider, a DNS SRV record, a blind connection on 5060 to an IP returned by an A record or manual registration via your provider website. (these are all method I've seen actually used, there may be others) After the caller connects via SIP to the called party they negotiate the connection. The "media channel" is usually negotiated by embedding SDP packets in the SIP exchange (it's all plain text, you can actually sniff it from the asterisk console, and in fact it's often necessary to be done to understand problems). There is absolutely no rule forcing RTP to be used as the media channel protocol, there are also others, but for phone calls that's what is usually negotiated. But RTP is a different protocol whose only relation to SIP is it being commonly used to actually relay the voice communication between endpoints. RTP is strictly defined to use UDP transport and is a monodirectional protocol, so for VoIP communication you need two RTP channels (or connections if you prefer), one for inbound and one for outbound. In the SDP negotiation each party (there no differentiation between caller and called party) will state where he expects the other party to send it's audio. Various information will be exchanged, including protocol audio format but most important for us IP:port. After negotiation each party performs the connection to the other. Let me rephrase: Your asterisk will be telling your provider to which IP:port is should send it's UDP connection for the audio stream, so you can't control where you are connecting (but that's not a problem, NAT correctly handles that) you have FULL CONTROL of the UDP port range the provider MUST use to connect to you (that is unless they are getting out of their way with a non compliant implementation, in such a case, look for a better provider). That said your situation is quite easy to solve without any special firewall configuration except redirecting a small (50-100) number of UDP ports of your choice. In real world situations this is quite handy since you rarely have full control of the router/firewall and many times all you get is a basic DSL modem/router with very limited FW/NAT functionality. On the other hand if you actually need thousands of UDP ports(that is thousands of simultaneous calls), most probably you also can get a static IP address for your PBX. On 09/26/2017 15:29, O. Hartmann wrote: > On Tue, 26 Sep 2017 11:27:05 +0200 > Guido Falsi <madpi...@freebsd.org> wrote: > > I already tried to build net/asterisk13 on my AARCH64 jail, but since I'd like > to have the databases/postgresql96-client aboard and this specific port fails > to build, I gave up - it is, by the way, the only port (pgsql) as far as I > know that fails in my poudriere cross compiling jail. I did not get further, > but I saw that it is supposed to build only for amd64 and armv6. > >> >> In such a case would you be willing to test port changes on the hardware >> to actually check it runs? > > I'd like to if the efforts are not to much time consuming - I do not have a > working Pine64 image anymore, but I have a Pine64 with 2GB RAM at hand. Months > ago I started playing with cross compiling world/kernel for AARCH64, but I'm > not familiar with crochet and preparing the SD image - but willing to do. But > beware: my home box preparing the cross cimpilation is not the fastest! > Actually, I don't have ARM64 hardware available right now and no ARM64 jail right now, maybe in a not to distant future I'll have that and be able to perform specific tests, but things standing as they are I cannot state anything definitive on this subject. > For the moment, the ARM based PBX should perform SoHo tasks - three, up to ten > lines at maximum. So you need at most 1 port for SIP and 20 for RTP...a 50 ports range will have space to spare. > >> >> On the other hand if you plan doing a lot of audio transcoding or some >> video transcoding, load can get up quite fast. Compressed codecs like >> the "simple" G729 will make your load grow relatively fast even with >&g
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, 26 Sep 2017 11:00:45 +0200 Damjan Jovanovic <damjan@gmail.com> wrote: > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartm...@walstatt.org> > wrote: > > > Hello, > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > > into > > several problems. My questions might have a "noobish" character, so my > > apology, > > my experiences with IPFW are not as thorough as they should be. > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > > coming soon also supported? > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > (assumed > > having 2 GB of RAM)? > > > > My main concern is about IPFW (we do not use PF for some reasons, I have to > > stay with IPFW). > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > > IPv6. > > The FreeBSD system acting as a router is supposed to have a jail soon > > containing the Asterisk 13 IP PBX (at the moment running on the main > > system). > > To provide access to the VoIP infrastructure inside/behind the router/NAT > > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > > UPD/TCP ports for VoIP to its destination network, and here I have a > > problem to > > solve. > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > > it > > is a mess and pain in the arse to forward a whole range, say 11000/udp - > > 35000/udp, which is a range one of my providers is sending RTP on. A second > > provider uses another range for RTP, starting at 5000/udp. So, the logical > > consequence would be a union set up UDP range to forward, which exapnds > > then > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > One of the most disturbing and well known problems is that due to the > > stateful > > firewall the RTP session very often is half duplex - it seems one direction > > of the RTP connection doesn't make it through IPFW/NAT. As often I search > > the > > net, I always get informed this is a typical problem and solutions are > > provided by so called ALGs - since SIP protocol's SDP indicates within the > > payload of the packets on which UDP ports both ends wish to establish their > > RTP session, it would be "easy" to pinhole the IPFW on exactly those ports > > for > > a theoretical large number of sessions, if IPFW could "divert" those > > packets > > to an instance inspecting SDP (or whatever is used for the RTP port > > indication, I'm new to that, sorry for the terminology) and then pinholing > > the > > NAT/IPFW for exactly this purpose without the forwarding mess. I came along > > netgraph() while searching for hints and hooks, but it seems a complete > > Linux > > domain, when it somes to appliances like VoIP/IP PBX. > > > > Either, the problem is that trivial on FreeBSD, so no further mentioning is > > necessary (which would explain the vast emptyness of explanations, hints > > and > > so on) or FreeBSD is a complete wasteland on this subject - which I also > > suspect, since pfSense and OPNsense must have come along with such problems > > and I simply do not know or recognise the software used for those purposes. > > > > So, if someone enlightened in this matter stumbles over my question and > > could > > delegate me onto the right way (ports, ng_XXX netgraph ficilities to look > > at, > > some ipfw techniques relevant to the problem apart from the stupid simple > > forwarding large ranges of ports) - I'd appreciate this and > > > > thanks in advance for patience and help, > > > > Oliver > > > > > Hi > > It might be easier if you just enable STUN on Asterisk, and build FreeBSD > from source with my [largely neglected :( ] patch on > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 > > That way Asterisk should dynamically discover consistent external mappings > for connections, making port forwarding RTP unnecessary. > > Damjan STUN is enabled, but my providers do not support STUN. I try to figure out how SIP works exactly to make my problem more precise. I also try to understand the aim of your patch - as far as I know, it does exactly as it is needed for the IPW/NAT/VoIP case. And I really regret that there are objections to commit the patch ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, Sep 26, 2017 at 3:44 PM, O. Hartmann <o.hartm...@walstatt.org> wrote: > On Tue, 26 Sep 2017 11:00:45 +0200 > Damjan Jovanovic <damjan@gmail.com> wrote: > > > On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartm...@walstatt.org> > > wrote: > > > > > Hello, > > > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I > ran > > > into > > > several problems. My questions might have a "noobish" character, so my > > > apology, > > > my experiences with IPFW are not as thorough as they should be. > > > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 > about > > > coming soon also supported? > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > > (assumed > > > having 2 GB of RAM)? > > > > > > My main concern is about IPFW (we do not use PF for some reasons, I > have to > > > stay with IPFW). > > > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not > yet > > > IPv6. > > > The FreeBSD system acting as a router is supposed to have a jail soon > > > containing the Asterisk 13 IP PBX (at the moment running on the main > > > system). > > > To provide access to the VoIP infrastructure inside/behind the > router/NAT > > > system, the in-kernel NAT facility of FreeBSD is forwarding the > relevant > > > UPD/TCP ports for VoIP to its destination network, and here I have a > > > problem to > > > solve. > > > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other > ports, > > > it > > > is a mess and pain in the arse to forward a whole range, say 11000/udp > - > > > 35000/udp, which is a range one of my providers is sending RTP on. A > second > > > provider uses another range for RTP, starting at 5000/udp. So, the > logical > > > consequence would be a union set up UDP range to forward, which exapnds > > > then > > > form 5000/udp to 45000/udp - which is much more a pain ... > > > > > > One of the most disturbing and well known problems is that due to the > > > stateful > > > firewall the RTP session very often is half duplex - it seems one > direction > > > of the RTP connection doesn't make it through IPFW/NAT. As often I > search > > > the > > > net, I always get informed this is a typical problem and solutions are > > > provided by so called ALGs - since SIP protocol's SDP indicates within > the > > > payload of the packets on which UDP ports both ends wish to establish > their > > > RTP session, it would be "easy" to pinhole the IPFW on exactly those > ports > > > for > > > a theoretical large number of sessions, if IPFW could "divert" those > > > packets > > > to an instance inspecting SDP (or whatever is used for the RTP port > > > indication, I'm new to that, sorry for the terminology) and then > pinholing > > > the > > > NAT/IPFW for exactly this purpose without the forwarding mess. I came > along > > > netgraph() while searching for hints and hooks, but it seems a complete > > > Linux > > > domain, when it somes to appliances like VoIP/IP PBX. > > > > > > Either, the problem is that trivial on FreeBSD, so no further > mentioning is > > > necessary (which would explain the vast emptyness of explanations, > hints > > > and > > > so on) or FreeBSD is a complete wasteland on this subject - which I > also > > > suspect, since pfSense and OPNsense must have come along with such > problems > > > and I simply do not know or recognise the software used for those > purposes. > > > > > > So, if someone enlightened in this matter stumbles over my question and > > > could > > > delegate me onto the right way (ports, ng_XXX netgraph ficilities to > look > > > at, > > > some ipfw techniques relevant to the problem apart from the stupid > simple > > > forwarding large ranges of ports) - I'd appreciate this and > > > > > > thanks in advance for patience and help, > > > > > > Oliver > > > > > > > > > Hi > > > > It might be easier if you just enable STUN on Asterisk, and build FreeBSD > > from source with my [largely neglected :( ] patch on > > https://bugs
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, 26 Sep 2017 11:27:05 +0200 Guido Falsi <madpi...@freebsd.org> wrote: > On 09/26/2017 10:35, O. Hartmann wrote: > > Hello, > > > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > > into several problems. My questions might have a "noobish" character, so my > > apology, my experiences with IPFW are not as thorough as they should be. > > > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > > coming soon also supported? > > I'm maintaining the asterisk ports. At present I don't have any ARM64 > hardware to test it on, but I plan to create an ARM64 jail in poudriere > so I can try to make it at least build there. Hello Guido, I posted by accident the question again to this list as I introduced a typo when sending it also to the IPFW list. I'm sorry. I already tried to build net/asterisk13 on my AARCH64 jail, but since I'd like to have the databases/postgresql96-client aboard and this specific port fails to build, I gave up - it is, by the way, the only port (pgsql) as far as I know that fails in my poudriere cross compiling jail. I did not get further, but I saw that it is supposed to build only for amd64 and armv6. > > In such a case would you be willing to test port changes on the hardware > to actually check it runs? I'd like to if the efforts are not to much time consuming - I do not have a working Pine64 image anymore, but I have a Pine64 with 2GB RAM at hand. Months ago I started playing with cross compiling world/kernel for AARCH64, but I'm not familiar with crochet and preparing the SD image - but willing to do. But beware: my home box preparing the cross cimpilation is not the fastest! > > > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > > (assumed having 2 GB of RAM)? > > That very much depends on the kind of load you are expecting. > > Asterisk can process a lot of calls. Especially if it can avoid being > in the media path. For the moment, the ARM based PBX should perform SoHo tasks - three, up to ten lines at maximum. > > On the other hand if you plan doing a lot of audio transcoding or some > video transcoding, load can get up quite fast. Compressed codecs like > the "simple" G729 will make your load grow relatively fast even with > audio transcoding. Transcoding also lowers call quality so it should > anyway be avoided as much as possible. Good to know. But the PBX is more like an experiment for "at home's PBX" and, if applicable, later for some fellows working scientifically in field and in need for some small and neat equipement. Video message/streaming is not so much the focus on the first attempts, but if possible, welcome. if not: not so tragic. > > Also load can go up if you're doing many disk operations. Monitoring and > saving audio for a bunch of calls can be quite heavy on disk resources > AND could require additional transcoding. There are Linux fellows running Asterisk 13 on raspberry Pi3 very successfully and this little box has only 1GB RAM as far as I know. Why should FreeBSD fail? > > > > > My main concern is about IPFW (we do not use PF for some reasons, I have to > > stay with IPFW). > > > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > > IPv6. The FreeBSD system acting as a router is supposed to have a jail soon > > containing the Asterisk 13 IP PBX (at the moment running on the main > > system). To provide access to the VoIP infrastructure inside/behind the > > router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the > > relevant UPD/TCP ports for VoIP to its destination network, and here I have > > a problem to solve. > > > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > > it is a mess and pain in the arse to forward a whole range, say 11000/udp - > > 35000/udp, which is a range one of my providers is sending RTP on. A second > > provider uses another range for RTP, starting at 5000/udp. So, the logical > > consequence would be a union set up UDP range to forward, which exapnds then > > form 5000/udp to 45000/udp - which is much more a pain ... > > The asterisk project has some suggestions on this here [1] I know those references as I'm with the problem now for a couple of months ... > > RTP with NAT+FW is a pain. I'm not aware of any IPFW tools able to > actively inspect SIP packets (which could also be encrypted if using > SIPS, so there would be no clean way to inspect them). > > Depending on your phone providers you could use a stun and/or turn > server by enabling t
FreeBSD, IPFW and the SIP/VoIP NAT problem
Hello, trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into several problems. My questions might have a "noobish" character, so my apology, my experiences with IPFW are not as thorough as they should be. Before I'll got into medias res, aquestion about Pine64/AARCH64: - port net/asterisk13 is supposed to build only on armv6, is aarch64 about coming soon also supported? - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed having 2 GB of RAM)? My main concern is about IPFW (we do not use PF for some reasons, I have to stay with IPFW). I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6. The FreeBSD system acting as a router is supposed to have a jail soon containing the Asterisk 13 IP PBX (at the moment running on the main system). To provide access to the VoIP infrastructure inside/behind the router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the relevant UPD/TCP ports for VoIP to its destination network, and here I have a problem to solve. While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it is a mess and pain in the arse to forward a whole range, say 11000/udp - 35000/udp, which is a range one of my providers is sending RTP on. A second provider uses another range for RTP, starting at 5000/udp. So, the logical consequence would be a union set up UDP range to forward, which exapnds then form 5000/udp to 45000/udp - which is much more a pain ... One of the most disturbing and well known problems is that due to the stateful firewall the RTP session very often is half duplex - it seems one direction of the RTP connection doesn't make it through IPFW/NAT. As often I search the net, I always get informed this is a typical problem and solutions are provided by so called ALGs - since SIP protocol's SDP indicates within the payload of the packets on which UDP ports both ends wish to establish their RTP session, it would be "easy" to pinhole the IPFW on exactly those ports for a theoretical large number of sessions, if IPFW could "divert" those packets to an instance inspecting SDP (or whatever is used for the RTP port indication, I'm new to that, sorry for the terminology) and then pinholing the NAT/IPFW for exactly this purpose without the forwarding mess. I came along netgraph() while searching for hints and hooks, but it seems a complete Linux domain, when it somes to appliances like VoIP/IP PBX. Either, the problem is that trivial on FreeBSD, so no further mentioning is necessary (which would explain the vast emptyness of explanations, hints and so on) or FreeBSD is a complete wasteland on this subject - which I also suspect, since pfSense and OPNsense must have come along with such problems and I simply do not know or recognise the software used for those purposes. So, if someone enlightened in this matter stumbles over my question and could delegate me onto the right way (ports, ng_XXX netgraph ficilities to look at, some ipfw techniques relevant to the problem apart from the stupid simple forwarding large ranges of ports) - I'd appreciate this and thanks in advance for patience and help, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On 09/26/2017 10:35, O. Hartmann wrote: > Hello, > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into > several problems. My questions might have a "noobish" character, so my > apology, > my experiences with IPFW are not as thorough as they should be. > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > coming soon also supported? I'm maintaining the asterisk ports. At present I don't have any ARM64 hardware to test it on, but I plan to create an ARM64 jail in poudriere so I can try to make it at least build there. In such a case would you be willing to test port changes on the hardware to actually check it runs? > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed > having 2 GB of RAM)? That very much depends on the kind of load you are expecting. Asterisk can process a lot of calls. Especially if it can avoid being in the media path. On the other hand if you plan doing a lot of audio transcoding or some video transcoding, load can get up quite fast. Compressed codecs like the "simple" G729 will make your load grow relatively fast even with audio transcoding. Transcoding also lowers call quality so it should anyway be avoided as much as possible. Also load can go up if you're doing many disk operations. Monitoring and saving audio for a bunch of calls can be quite heavy on disk resources AND could require additional transcoding. > > My main concern is about IPFW (we do not use PF for some reasons, I have to > stay with IPFW). > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > IPv6. > The FreeBSD system acting as a router is supposed to have a jail soon > containing the Asterisk 13 IP PBX (at the moment running on the main system). > To provide access to the VoIP infrastructure inside/behind the router/NAT > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > UPD/TCP ports for VoIP to its destination network, and here I have a problem > to > solve. > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it > is a mess and pain in the arse to forward a whole range, say 11000/udp - > 35000/udp, which is a range one of my providers is sending RTP on. A second > provider uses another range for RTP, starting at 5000/udp. So, the logical > consequence would be a union set up UDP range to forward, which exapnds then > form 5000/udp to 45000/udp - which is much more a pain ... The asterisk project has some suggestions on this here [1] RTP with NAT+FW is a pain. I'm not aware of any IPFW tools able to actively inspect SIP packets (which could also be encrypted if using SIPS, so there would be no clean way to inspect them). Depending on your phone providers you could use a stun and/or turn server by enabling the ICE protocol [2], which are all technologies supported by asterisk, but require support from your provider. Another option is symmetric RTP, which is a trick by creating symmetric port numbers connections which sometimes can trick firewalls properly configured. You setup also forces you to keep asterisk in the media path (direct_media=no in peer configuration) Unluckily none of these technologies is 100% bulletproof. RTP is not made to play well with NAT, so the professional solution is to spare an IP and redirect almost all ports to the SIP/RTP box. Also it's much better to do this with static rules, to avoid load problems on the FW (see later). You can sidestep the whole issue by running a proxy on your firewall machine, if you have control of it. There are a few in the ports tree. Take a look at: net/kamailio - It is really a SIP proxy, but can parse SIP/SDP packets and modify their content on the fly, allowing you to play neat tricks. Requires some knowledge of the protocol and work though. (maybe you can get him to punch holes in the firewall, but I have not checked if it's possible) net/rtpproxy: this is more specific and maybe your best bet. Beware of the load of proxying RTP in userland though. > > One of the most disturbing and well known problems is that due to the stateful > firewall the RTP session very often is half duplex - it seems one direction Depending on how many simultaneous SIP calls you plan to manage keep an eye on your firewall too. each call will create at least 3 states, one for SIP and one for each leg of the RTP stream, so it can pile up quite fast. > of the RTP connection doesn't make it through IPFW/NAT. As often I search the > net, I always get informed this is a typical problem and solutions are > provided by so called ALGs - since SIP protocol's SDP indicates within the This would require coding it in IPFW, and the load on the firewall could be significant. It could be don
Re: FreeBSD, IPFW and the SIP/VoIP NAT problem
On Tue, Sep 26, 2017 at 10:35 AM, O. Hartmann <ohartm...@walstatt.org> wrote: > Hello, > > trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran > into > several problems. My questions might have a "noobish" character, so my > apology, > my experiences with IPFW are not as thorough as they should be. > > Before I'll got into medias res, aquestion about Pine64/AARCH64: > > - port net/asterisk13 is supposed to build only on armv6, is aarch64 about > coming soon also supported? > - would a Pine64 running CURRENT (12) be sufficient as a PBX platform > (assumed > having 2 GB of RAM)? > > My main concern is about IPFW (we do not use PF for some reasons, I have to > stay with IPFW). > > I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet > IPv6. > The FreeBSD system acting as a router is supposed to have a jail soon > containing the Asterisk 13 IP PBX (at the moment running on the main > system). > To provide access to the VoIP infrastructure inside/behind the router/NAT > system, the in-kernel NAT facility of FreeBSD is forwarding the relevant > UPD/TCP ports for VoIP to its destination network, and here I have a > problem to > solve. > > While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, > it > is a mess and pain in the arse to forward a whole range, say 11000/udp - > 35000/udp, which is a range one of my providers is sending RTP on. A second > provider uses another range for RTP, starting at 5000/udp. So, the logical > consequence would be a union set up UDP range to forward, which exapnds > then > form 5000/udp to 45000/udp - which is much more a pain ... > > One of the most disturbing and well known problems is that due to the > stateful > firewall the RTP session very often is half duplex - it seems one direction > of the RTP connection doesn't make it through IPFW/NAT. As often I search > the > net, I always get informed this is a typical problem and solutions are > provided by so called ALGs - since SIP protocol's SDP indicates within the > payload of the packets on which UDP ports both ends wish to establish their > RTP session, it would be "easy" to pinhole the IPFW on exactly those ports > for > a theoretical large number of sessions, if IPFW could "divert" those > packets > to an instance inspecting SDP (or whatever is used for the RTP port > indication, I'm new to that, sorry for the terminology) and then pinholing > the > NAT/IPFW for exactly this purpose without the forwarding mess. I came along > netgraph() while searching for hints and hooks, but it seems a complete > Linux > domain, when it somes to appliances like VoIP/IP PBX. > > Either, the problem is that trivial on FreeBSD, so no further mentioning is > necessary (which would explain the vast emptyness of explanations, hints > and > so on) or FreeBSD is a complete wasteland on this subject - which I also > suspect, since pfSense and OPNsense must have come along with such problems > and I simply do not know or recognise the software used for those purposes. > > So, if someone enlightened in this matter stumbles over my question and > could > delegate me onto the right way (ports, ng_XXX netgraph ficilities to look > at, > some ipfw techniques relevant to the problem apart from the stupid simple > forwarding large ranges of ports) - I'd appreciate this and > > thanks in advance for patience and help, > > Oliver > Hi It might be easier if you just enable STUN on Asterisk, and build FreeBSD from source with my [largely neglected :( ] patch on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219918 That way Asterisk should dynamically discover consistent external mappings for connections, making port forwarding RTP unnecessary. Damjan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD, IPFW and the SIP/VoIP NAT problem
Hello, trying to build a FreeBSD based router/PBX (Asterisk 13) appliance, I ran into several problems. My questions might have a "noobish" character, so my apology, my experiences with IPFW are not as thorough as they should be. Before I'll got into medias res, aquestion about Pine64/AARCH64: - port net/asterisk13 is supposed to build only on armv6, is aarch64 about coming soon also supported? - would a Pine64 running CURRENT (12) be sufficient as a PBX platform (assumed having 2 GB of RAM)? My main concern is about IPFW (we do not use PF for some reasons, I have to stay with IPFW). I'm a customer of two ITSPs and my SoHo network is behind NAT and not yet IPv6. The FreeBSD system acting as a router is supposed to have a jail soon containing the Asterisk 13 IP PBX (at the moment running on the main system). To provide access to the VoIP infrastructure inside/behind the router/NAT system, the in-kernel NAT facility of FreeBSD is forwarding the relevant UPD/TCP ports for VoIP to its destination network, and here I have a problem to solve. While it is sumple and easy to forward 5060/udp, 5070/tcp and other ports, it is a mess and pain in the arse to forward a whole range, say 11000/udp - 35000/udp, which is a range one of my providers is sending RTP on. A second provider uses another range for RTP, starting at 5000/udp. So, the logical consequence would be a union set up UDP range to forward, which exapnds then form 5000/udp to 45000/udp - which is much more a pain ... One of the most disturbing and well known problems is that due to the stateful firewall the RTP session very often is half duplex - it seems one direction of the RTP connection doesn't make it through IPFW/NAT. As often I search the net, I always get informed this is a typical problem and solutions are provided by so called ALGs - since SIP protocol's SDP indicates within the payload of the packets on which UDP ports both ends wish to establish their RTP session, it would be "easy" to pinhole the IPFW on exactly those ports for a theoretical large number of sessions, if IPFW could "divert" those packets to an instance inspecting SDP (or whatever is used for the RTP port indication, I'm new to that, sorry for the terminology) and then pinholing the NAT/IPFW for exactly this purpose without the forwarding mess. I came along netgraph() while searching for hints and hooks, but it seems a complete Linux domain, when it somes to appliances like VoIP/IP PBX. Either, the problem is that trivial on FreeBSD, so no further mentioning is necessary (which would explain the vast emptyness of explanations, hints and so on) or FreeBSD is a complete wasteland on this subject - which I also suspect, since pfSense and OPNsense must have come along with such problems and I simply do not know or recognise the software used for those purposes. So, if someone enlightened in this matter stumbles over my question and could delegate me onto the right way (ports, ng_XXX netgraph ficilities to look at, some ipfw techniques relevant to the problem apart from the stupid simple forwarding large ranges of ports) - I'd appreciate this and thanks in advance for patience and help, Oliver ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPFW on CURRENT: NAT forwarding exposes internal IP!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am Thu, 29 Sep 2016 16:00:10 +0300
Daniel Kalchev <dan...@digsys.bg> schrieb:
Yes, your are right :-)
Yes, I'm wrong, it is not NAT :-(
Thanks a lot,
Oliver
> It looks like your httpd server is doing a redirect to your internal IP
> address, which
> it thinks is it’s ServerName. Don’t think NAT has anything to do with it.
>
> Daniel
>
> > On 29.09.2016 г., at 15:47, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> >
> > Despite other problems with IPFW and its documentation regarding NAT, I
> > face a serious
> > and disturbing problem.
> >
> > I run a NanoBSD based router/firewall project of my own, running CURRENT
> > (FreeBSD
> > 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the filter
> > of my
> > choice, since it is FreeBSD's native. I also use In-kernel-NAT as well as
> > pppoed/ppp.
> > The modem is connected to a dedicated NIC, the pppoe-traffic is transported
> > via tun0
> > - I think this is the usual stuff.
> >
> > The IPFW has this NAT rule:
> >
> > ${fwcmd}nat 1 config if ${if_isp0} \
> >log \
> >reset \
> >same_ports \
> >redirect_port tcp ${server_gate}:22 22 \
> >redirect_port tcp ${server_www}:80 80 \
> >redirect_port tcp ${server_www}:443 443 \
> >redirect_port tcp ${server_refdb}:9734 9734
> >
> > server_www is assigned to a non-official IP, 192.168.10.10.
> >
> > if_isp=tun0, tun0's IP is given by the provider, I use net/ddclient as the
> > updater
> > for a dynamic DNS account.
> >
> > I use an internal DNS server, which resolves 92.168.10.10 to a certain
> > name. I also
> > use self signed SSL certicates, just for completeness of this information.
> >
> > Connecting from the outside world to my dynDNS domain triggers Firefox or
> > any other
> > browser to compalin about the self signed SSL certificate - as usual, but
> > then, adding
> > it, suddenly the domain name (say: www.blabla.org) is replaced by the
> > internal IP I
> > delegate any access on ports 80 and 443 to.
> >
> > What happens here? I consider this a bug, I never saw this on our Linux
> > servers
> > running a similar setup (forwarding, BIND 9.10/BIND 9.11).
> >
> > Thanks,
> >
> > Oliver
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3
> > yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp
> > ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04
> > 9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD
> > 20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc
> > K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=
> > =oMGL
> > -END PGP SIGNATURE-
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJX7RX7AAoJEOgBcD7A/5N85rAH/jbwR0yd1bE0a9OIukfJyf2Y
3s+O+GQakxZJmYD6vv+k+6M2qD9TFsrCHmHylNfsV5gBirFZe6gEHRibXnvnlQxy
JmXniK2o/HXl/NDxEKTshqX6xtS+xeow7IhObCG42OaZrxUdKgX3qfgY13VKEVM1
9NdLv0EE0veK+EnxmxnBSDl2h5wV69pK1Ra+iLSSfYeO+VMMH2eUK6jbh/S4cB5h
AJ4oK08by4SNOsovMwtKLF+U1NHaDuHKWG92rXU1mYN/M3rqtVgVpq040tOVDFpC
Nylhj4e1XRnM/U3Y7VBztfTN4EXGRK8D+m1fOXGiPnet30vhd3kYFRhTF5vnf1U=
=LumJ
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IPFW on CURRENT: NAT forwarding exposes internal IP!
It looks like your httpd server is doing a redirect to your internal IP
address, which it thinks is it’s ServerName. Don’t think NAT has anything to do
with it.
Daniel
> On 29.09.2016 г., at 15:47, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Despite other problems with IPFW and its documentation regarding NAT, I face
> a serious
> and disturbing problem.
>
> I run a NanoBSD based router/firewall project of my own, running CURRENT
> (FreeBSD
> 12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the filter
> of my choice,
> since it is FreeBSD's native. I also use In-kernel-NAT as well as pppoed/ppp.
> The modem
> is connected to a dedicated NIC, the pppoe-traffic is transported via tun0 -
> I think this
> is the usual stuff.
>
> The IPFW has this NAT rule:
>
> ${fwcmd}nat 1 config if ${if_isp0} \
>log \
>reset \
>same_ports \
>redirect_port tcp ${server_gate}:22 22 \
>redirect_port tcp ${server_www}:80 80 \
>redirect_port tcp ${server_www}:443 443 \
>redirect_port tcp ${server_refdb}:9734 9734
>
> server_www is assigned to a non-official IP, 192.168.10.10.
>
> if_isp=tun0, tun0's IP is given by the provider, I use net/ddclient as the
> updater for a
> dynamic DNS account.
>
> I use an internal DNS server, which resolves 92.168.10.10 to a certain name.
> I also use
> self signed SSL certicates, just for completeness of this information.
>
> Connecting from the outside world to my dynDNS domain triggers Firefox or any
> other
> browser to compalin about the self signed SSL certificate - as usual, but
> then, adding
> it, suddenly the domain name (say: www.blabla.org) is replaced by the
> internal IP I
> delegate any access on ports 80 and 443 to.
>
> What happens here? I consider this a bug, I never saw this on our Linux
> servers running a
> similar setup (forwarding, BIND 9.10/BIND 9.11).
>
> Thanks,
>
> Oliver
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3
> yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp
> ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04
> 9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD
> 20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc
> K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=
> =oMGL
> -END PGP SIGNATURE-
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
IPFW on CURRENT: NAT forwarding exposes internal IP!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Despite other problems with IPFW and its documentation regarding NAT, I face a
serious
and disturbing problem.
I run a NanoBSD based router/firewall project of my own, running CURRENT
(FreeBSD
12.0-CURRENT #1 r306333: Mon Sep 26 08:36:02 CEST 2016). IPFW is the filter of
my choice,
since it is FreeBSD's native. I also use In-kernel-NAT as well as pppoed/ppp.
The modem
is connected to a dedicated NIC, the pppoe-traffic is transported via tun0 - I
think this
is the usual stuff.
The IPFW has this NAT rule:
${fwcmd}nat 1 config if ${if_isp0} \
log \
reset \
same_ports \
redirect_port tcp ${server_gate}:22 22 \
redirect_port tcp ${server_www}:80 80 \
redirect_port tcp ${server_www}:443 443 \
redirect_port tcp ${server_refdb}:9734 9734
server_www is assigned to a non-official IP, 192.168.10.10.
if_isp=tun0, tun0's IP is given by the provider, I use net/ddclient as the
updater for a
dynamic DNS account.
I use an internal DNS server, which resolves 92.168.10.10 to a certain name. I
also use
self signed SSL certicates, just for completeness of this information.
Connecting from the outside world to my dynDNS domain triggers Firefox or any
other
browser to compalin about the self signed SSL certificate - as usual, but then,
adding
it, suddenly the domain name (say: www.blabla.org) is replaced by the internal
IP I
delegate any access on ports 80 and 443 to.
What happens here? I consider this a bug, I never saw this on our Linux servers
running a
similar setup (forwarding, BIND 9.10/BIND 9.11).
Thanks,
Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJX7Q17AAoJEOgBcD7A/5N88yAH/RZLURQbC5LTgJD/NUdE51F3
yPVaUQIaeGm93du87K2opXs3DNtMr0m1SI1wQZdOAQDl3yqMkz9bX9VTUweuAltp
ZcBxhZ2VACQJCu/AsYIWWWp6rliniyZWMr+TOyNtTDxdPrIXYzwefX+fYN+Uy/04
9PalfcT/S+9q5DKd7sm7K6LqsU0HJ9GpKgNnsyqWEAWvORgxUvKS3GS9jEjxUnrD
20yTXjyiu0mS8UYLS7DbrrgItg3fXEJVG8188tweFB5aalQRH6oyNGaxWlGaF8Rc
K9t479v6OW3XCs9FiG6AtCzpmnUkCoMtxl7lY3hPU/Sh1P5epYu26bdoF2ecr1g=
=oMGL
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On Tue, Nov 10, 2015 at 1:28 PM, Kristof Provost <k...@freebsd.org> wrote: > On 2015-11-09 21:47:01 (-0500), Shawn Webb <shawn.w...@hardenedbsd.org> wrote: >> I found the problem: it seems that the new Intel Haswell graphics >> support (which I've been running with) is at odds somehow with pf NAT. >> Removing Haswell graphics support means working pf NAT. >> > That's ... very strange. > > I've built the drm-i915-update-38 branch of > http:github.com/freebsd/freebsd-base-graphics.git, > but still haven't managed to reproduce the problem. > It is if course entirely possible that it would only manifest if the > haswell graphics are actually in use. In that case there's little I can > do as I don't have haswell hardware I could test on. 1. Add memguard(9) support to kernel. 2. Set the descriptions for the zones (as noted in the manpage) to catch panics when either driver tries to touch eachothers' space. Cheers, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On 2015-11-09 21:47:01 (-0500), Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > I found the problem: it seems that the new Intel Haswell graphics > support (which I've been running with) is at odds somehow with pf NAT. > Removing Haswell graphics support means working pf NAT. > That's ... very strange. I've built the drm-i915-update-38 branch of http:github.com/freebsd/freebsd-base-graphics.git, but still haven't managed to reproduce the problem. It is if course entirely possible that it would only manifest if the haswell graphics are actually in use. In that case there's little I can do as I don't have haswell hardware I could test on. Regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On Tue, Nov 10, 2015 at 01:45:21PM -0800, NGie Cooper wrote: > On Tue, Nov 10, 2015 at 1:28 PM, Kristof Provost <k...@freebsd.org> wrote: > > On 2015-11-09 21:47:01 (-0500), Shawn Webb <shawn.w...@hardenedbsd.org> > > wrote: > >> I found the problem: it seems that the new Intel Haswell graphics > >> support (which I've been running with) is at odds somehow with pf NAT. > >> Removing Haswell graphics support means working pf NAT. > >> > > That's ... very strange. > > > > I've built the drm-i915-update-38 branch of > > http:github.com/freebsd/freebsd-base-graphics.git, > > but still haven't managed to reproduce the problem. > > It is if course entirely possible that it would only manifest if the > > haswell graphics are actually in use. In that case there's little I can > > do as I don't have haswell hardware I could test on. > > 1. Add memguard(9) support to kernel. > 2. Set the descriptions for the zones (as noted in the manpage) to > catch panics when either driver tries to touch eachothers' space. > Cheers, > -NGie I think I might've been between some major pf commits or had some sort of stale file. I updated to latest HEAD with the new haswell stuff merged in and all is well. Thanks for the help in troubleshooting this. I'll keep an eye on it. Thanks, -- Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE pgpiJKCpVf0bx.pgp Description: PGP signature
Re: pf NAT and VNET Jails
On Thursday, 05 November 2015 11:45:25 PM Kristof Provost wrote:
> > On 05 Nov 2015, at 17:25, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
> > I've figured it out. I've removed all rules and went with a barebones
> > config.
> >
> > Right now, the laptop I'm using for NAT has an outbound interface of wlan0
> > with an IP of 129.6.251.181 (from DHCP). The following line works:
> >
> > nat on wlan0 from any to any -> 129.6.251.181
> >
> > The following line doesn't:
> >
> > nat on wlan0 from any to any -> (wlan0)
> >
> > Nor does this:
> >
> > nat on wlan0 from any to any -> wlan0
> >
> > From the Handbook, the lines that don't work are prefered especially the
> > first non-working line, since using (wlan0) would cause pf to pick up
> > wlan0's IP dynamically (which is good, since wlan0 is DHCP'd).
> >
> > So it seems at some point of time, doing NAT dynamically broke.
>
> So far I’ve had no luck reproducing this.
> With pf.conf:
> nat on vtnet0 from any to any -> (vtnet0)
> pass in
> pass out
>
> And setup code:
> ifconfig bridge0 create
> ifconfig epair0 create
> ifconfig epair0a up
> ifconfig epair0b up
> ifconfig bridge0 addm epair0a
>
> jail -c name=test host.hostname=test vnet persist
> ifconfig epair0b vnet test
>
> ifconfig bridge0 inet 10.0.0.1/24
>
> jexec test ifconfig epair0b 10.0.0.2/23
> jexec test route add default 10.0.0.1
>
> # Activate routing
> sysctl net.inet.ip.forwarding=1
>
> pfctl -e
> pfctl -g -f pf.conf
>
> Then I run exec test ping 8.8.8.8, which works as expected.
>
> My home routing is running CURRENT, used vnet jails and also doesn’t seem to
> be triggering the problem.
>
> Perhaps we’re still missing a component of the problem, but right now I have
> no idea what that would be.
>
> Hmm. Perhaps… do you happen to know in what order things are done during
> startup? Perhaps it’s related to the fact that wlan0 is both wifi and DHCP,
> in the sense that pf is configured before the IP is assigned to the
> interface.
>
> Can you try reloading pf with the (wlan0) rule? (Just pfctl -g -f
> /etc/pf.conf should do the trick).
I'm using iocage for jailing.
It's now looking like pf is back to being broken for me. I've tried every
combination possible, even hardcoding the values:
nat on wlan0 from {192.168.6.0/24, 192.168.7.0/24} to any -> 129.6.251.181
pass in
pass out
I have zero idea why this isn't working. It seems that from the documentation,
I'm doing everything right. I can see from tcpdump that the packets are
getting forwarded, but without the src IP address being rewritten to
129.6.251.181.
tcpdump output for a single ICMP packet, pinging to 8.8.8.8:
08:12:30.544462 IP 192.168.7.3 > 8.8.8.8: ICMP echo request, id 28131, seq 0,
length 64
That src IP should say 129.6.251.181.
Thanks,
--
Shawn Webb
HardenedBSD
GPG Key ID:0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: This is a digitally signed message part.
Re: pf NAT and VNET Jails
On Mon, Nov 09, 2015 at 08:18:32AM -0500, Shawn Webb wrote:
> I'm using iocage for jailing.
>
> It's now looking like pf is back to being broken for me. I've tried every
> combination possible, even hardcoding the values:
>
> nat on wlan0 from {192.168.6.0/24, 192.168.7.0/24} to any -> 129.6.251.181
> pass in
> pass out
>
> I have zero idea why this isn't working. It seems that from the
> documentation,
> I'm doing everything right. I can see from tcpdump that the packets are
> getting forwarded, but without the src IP address being rewritten to
> 129.6.251.181.
>
> tcpdump output for a single ICMP packet, pinging to 8.8.8.8:
>
> 08:12:30.544462 IP 192.168.7.3 > 8.8.8.8: ICMP echo request, id 28131, seq 0,
> length 64
>
> That src IP should say 129.6.251.181.
I found the problem: it seems that the new Intel Haswell graphics
support (which I've been running with) is at odds somehow with pf NAT.
Removing Haswell graphics support means working pf NAT.
Thanks,
--
Shawn Webb
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
pgpK8LBaWhTDU.pgp
Description: PGP signature
Re: pf NAT and VNET Jails
On Tuesday, 03 November 2015 12:44:19 AM Kristof Provost wrote: > > On 02 Nov 2015, at 15:07, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > On Monday, 02 November 2015 02:59:03 PM Kristof Provost wrote: > >> Can you add your pf.conf too? > >> > >> I’ll try upgrading my machine to something beyond 290228 to see if I can > >> reproduce it. It’s on r289635 now, and seems to be fine. My VNET jails > >> certainly get their traffic NATed. > > > > Sorry about that! I should've included it. It's pasted here: > > http://ix.io/lLI > > > > It's probably not the most concise. This is a laptop that can have one of > > three interfaces online: re0 (ethernet on the laptop), wlan0 (you can > > guess > > what that is), or ue0 (usb tethering from my phone). I used to be able to > > specify NATing like that and pf would automatically figure out which > > outgoing device to use. Seems like that's broken now. > > I’ve updated my machine and things still seem to be working. > As you said, it’s probably related to the multiple nat entries. > > I’ll have to make a test setup, which’ll take a bit of time, especially > since I’m messing with the host machine at the moment. I've figured it out. I've removed all rules and went with a barebones config. Right now, the laptop I'm using for NAT has an outbound interface of wlan0 with an IP of 129.6.251.181 (from DHCP). The following line works: nat on wlan0 from any to any -> 129.6.251.181 The following line doesn't: nat on wlan0 from any to any -> (wlan0) Nor does this: nat on wlan0 from any to any -> wlan0 From the Handbook, the lines that don't work are prefered especially the first non-working line, since using (wlan0) would cause pf to pick up wlan0's IP dynamically (which is good, since wlan0 is DHCP'd). So it seems at some point of time, doing NAT dynamically broke. -- Shawn Webb HardenedBSD GPG Key ID:0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: This is a digitally signed message part.
Re: pf NAT and VNET Jails
> On 05 Nov 2015, at 17:25, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > I've figured it out. I've removed all rules and went with a barebones config. > > Right now, the laptop I'm using for NAT has an outbound interface of wlan0 > with an IP of 129.6.251.181 (from DHCP). The following line works: > > nat on wlan0 from any to any -> 129.6.251.181 > > The following line doesn't: > > nat on wlan0 from any to any -> (wlan0) > > Nor does this: > > nat on wlan0 from any to any -> wlan0 > > From the Handbook, the lines that don't work are prefered especially the first > non-working line, since using (wlan0) would cause pf to pick up wlan0's IP > dynamically (which is good, since wlan0 is DHCP'd). > > So it seems at some point of time, doing NAT dynamically broke. > So far I’ve had no luck reproducing this. With pf.conf: nat on vtnet0 from any to any -> (vtnet0) pass in pass out And setup code: ifconfig bridge0 create ifconfig epair0 create ifconfig epair0a up ifconfig epair0b up ifconfig bridge0 addm epair0a jail -c name=test host.hostname=test vnet persist ifconfig epair0b vnet test ifconfig bridge0 inet 10.0.0.1/24 jexec test ifconfig epair0b 10.0.0.2/23 jexec test route add default 10.0.0.1 # Activate routing sysctl net.inet.ip.forwarding=1 pfctl -e pfctl -g -f pf.conf Then I run exec test ping 8.8.8.8, which works as expected. My home routing is running CURRENT, used vnet jails and also doesn’t seem to be triggering the problem. Perhaps we’re still missing a component of the problem, but right now I have no idea what that would be. Hmm. Perhaps… do you happen to know in what order things are done during startup? Perhaps it’s related to the fact that wlan0 is both wifi and DHCP, in the sense that pf is configured before the IP is assigned to the interface. Can you try reloading pf with the (wlan0) rule? (Just pfctl -g -f /etc/pf.conf should do the trick). Regards, Kristof signature.asc Description: Message signed with OpenPGP using GPGMail
Re: pf NAT and VNET Jails
On Sunday, 01 November 2015 07:16:34 AM Julian Elischer wrote: > On 11/1/15 2:50 AM, Shawn Webb wrote: > > I'm at r290228 on amd64. I'm not sure which revision I was on last when it > > last worked, but it seems VNET jails aren't working anymore. > > > > I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set > > their default route to 192.168.7.1. The host simply NATs outbound from > > 192.168.7.0/24 to the rest of the world. The various epairs get added to > > bridge1 and assigned to each jail. Pretty simple setup. That worked until > > today. When I do tcpdump on my public-facing NIC, I see that NAT isn't > > applied. When I run `ping 8.8.8.8` from the jail, the jail's > > 192.168.7.0/24 > > address gets sent on the wire. > > > > Let me know what I can do to help debug this further. > > send the list your setup script/settings? I'm using iocage to start up the jails. Here's a pasted output of `iocage get all mutt-hardenedbsd`: http://ix.io/lLG Thanks, -- Shawn Webb HardenedBSD GPG Key ID:0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: This is a digitally signed message part.
Re: pf NAT and VNET Jails
On Monday, 02 November 2015 02:59:03 PM Kristof Provost wrote: > > On 02 Nov 2015, at 14:47, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > On Sunday, 01 November 2015 07:16:34 AM Julian Elischer wrote: > >> On 11/1/15 2:50 AM, Shawn Webb wrote: > >>> I'm at r290228 on amd64. I'm not sure which revision I was on last when > >>> it > >>> last worked, but it seems VNET jails aren't working anymore. > >>> > >>> I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails > >>> set > >>> their default route to 192.168.7.1. The host simply NATs outbound from > >>> 192.168.7.0/24 to the rest of the world. The various epairs get added to > >>> bridge1 and assigned to each jail. Pretty simple setup. That worked > >>> until > >>> today. When I do tcpdump on my public-facing NIC, I see that NAT isn't > >>> applied. When I run `ping 8.8.8.8` from the jail, the jail's > >>> 192.168.7.0/24 > >>> address gets sent on the wire. > >>> > >>> Let me know what I can do to help debug this further. > >> > >> send the list your setup script/settings? > > > > I'm using iocage to start up the jails. Here's a pasted output of `iocage > > get all mutt-hardenedbsd`: http://ix.io/lLG > > Can you add your pf.conf too? > > I’ll try upgrading my machine to something beyond 290228 to see if I can > reproduce it. It’s on r289635 now, and seems to be fine. My VNET jails > certainly get their traffic NATed. Sorry about that! I should've included it. It's pasted here: http://ix.io/lLI It's probably not the most concise. This is a laptop that can have one of three interfaces online: re0 (ethernet on the laptop), wlan0 (you can guess what that is), or ue0 (usb tethering from my phone). I used to be able to specify NATing like that and pf would automatically figure out which outgoing device to use. Seems like that's broken now. Thanks, -- Shawn Webb HardenedBSD GPG Key ID:0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: This is a digitally signed message part.
Re: pf NAT and VNET Jails
> On 02 Nov 2015, at 14:47, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Sunday, 01 November 2015 07:16:34 AM Julian Elischer wrote: >> On 11/1/15 2:50 AM, Shawn Webb wrote: >>> I'm at r290228 on amd64. I'm not sure which revision I was on last when it >>> last worked, but it seems VNET jails aren't working anymore. >>> >>> I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set >>> their default route to 192.168.7.1. The host simply NATs outbound from >>> 192.168.7.0/24 to the rest of the world. The various epairs get added to >>> bridge1 and assigned to each jail. Pretty simple setup. That worked until >>> today. When I do tcpdump on my public-facing NIC, I see that NAT isn't >>> applied. When I run `ping 8.8.8.8` from the jail, the jail's >>> 192.168.7.0/24 >>> address gets sent on the wire. >>> >>> Let me know what I can do to help debug this further. >> >> send the list your setup script/settings? > > I'm using iocage to start up the jails. Here's a pasted output of `iocage get > all mutt-hardenedbsd`: http://ix.io/lLG Can you add your pf.conf too? I’ll try upgrading my machine to something beyond 290228 to see if I can reproduce it. It’s on r289635 now, and seems to be fine. My VNET jails certainly get their traffic NATed. Thanks, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
> On 02 Nov 2015, at 15:07, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > On Monday, 02 November 2015 02:59:03 PM Kristof Provost wrote: >> >> Can you add your pf.conf too? >> >> I’ll try upgrading my machine to something beyond 290228 to see if I can >> reproduce it. It’s on r289635 now, and seems to be fine. My VNET jails >> certainly get their traffic NATed. > > Sorry about that! I should've included it. It's pasted here: http://ix.io/lLI > > It's probably not the most concise. This is a laptop that can have one of > three interfaces online: re0 (ethernet on the laptop), wlan0 (you can guess > what that is), or ue0 (usb tethering from my phone). I used to be able to > specify NATing like that and pf would automatically figure out which outgoing > device to use. Seems like that's broken now. > I’ve updated my machine and things still seem to be working. As you said, it’s probably related to the multiple nat entries. I’ll have to make a test setup, which’ll take a bit of time, especially since I’m messing with the host machine at the moment. Regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pf NAT and VNET Jails
I'm at r290228 on amd64. I'm not sure which revision I was on last when it last worked, but it seems VNET jails aren't working anymore. I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set their default route to 192.168.7.1. The host simply NATs outbound from 192.168.7.0/24 to the rest of the world. The various epairs get added to bridge1 and assigned to each jail. Pretty simple setup. That worked until today. When I do tcpdump on my public-facing NIC, I see that NAT isn't applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 address gets sent on the wire. Let me know what I can do to help debug this further. Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pf NAT and VNET Jails
On 11/1/15 2:50 AM, Shawn Webb wrote: I'm at r290228 on amd64. I'm not sure which revision I was on last when it last worked, but it seems VNET jails aren't working anymore. I've got a bridge, bridge1, with an IP of 192.168.7.1. The VNET jails set their default route to 192.168.7.1. The host simply NATs outbound from 192.168.7.0/24 to the rest of the world. The various epairs get added to bridge1 and assigned to each jail. Pretty simple setup. That worked until today. When I do tcpdump on my public-facing NIC, I see that NAT isn't applied. When I run `ping 8.8.8.8` from the jail, the jail's 192.168.7.0/24 address gets sent on the wire. Let me know what I can do to help debug this further. send the list your setup script/settings? Thanks, Shawn Webb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Has anything changed from 8.2 to 9.0 that i missed to consider in configuration? Yes, the implementation was updated ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Hello,
i recently switched a router in our test-environment to FreeBSD 9.0-Beta3
(and after things didnt worked ... checked out the current RELENG_9
and recompiled kernel world .. )
Problem:
After 5 - 15 minutes NAT stops working (normal routing still works.)
Network Utilization: about 40 MByte/second, which gets routed
only a few kbit/s are getting natted (NTP Syncs and such ... )
When i took a look on the nat rules (via pfctl -vv -s nat)
the rules gets evaluated; but nothing matches anymore...
State Table helds about 9500 Entrys,
Source Tracking Table about 300
Software / Configuration:
pf, carp
pf.conf:
set limit src-nodes 55
set limit frags 32000
set timeout { adaptive.start 53 adaptive.end 54 }
set timeout src.track 600
set timeout frag 30
set skip on lo0
set skip on igb2
set skip on igb3
set skip on bce0
set skip on bce1
set skip on pfsync0
#set skip on internal
#set skip on carp3internal
nat on public from 10.5.0.0/16 to any - { public }
carp device holding the internal gateway ips (10.5.0.253 .. ),
currently master - no slave
/etc/sysctl.conf:
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.ip.forwarding=1
net.inet.ip.fastforwarding=1
net.inet.icmp.icmplim_output=0
net.inet.icmp.icmplim=0
net.route.netisr_maxqlen=8192
kern.random.sys.harvest.interrupt=0
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
net.inet.carp.preempt=1
/boot/loader.conf:
net.isr.maxthreads=2
net.isr.defaultqlimit=4096
net.isr.maxqlimit=81920
net.isr.direct=1
net.isr.bindthreads=1
hw.igb.num_queues=2
hw.igb.enable_aim=1
hw.igb.txd=2048
hw.igb.rxd=2048
hw.igb.max_interrupt_rate=8000
hw.intr_storm_threshold=1
kern.ipc.nmbclusters=262144
kern.hz=1000
# sysctl -a hw.igb
hw.igb.rx_process_limit: 100
hw.igb.num_queues: 2
hw.igb.header_split: 0
hw.igb.max_interrupt_rate: 8000
hw.igb.enable_msix: 1
hw.igb.enable_aim: 1
hw.igb.txd: 2048
hw.igb.rxd: 2048
# sysctl -a dev.igb
dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5
dev.igb.0.%driver: igb
dev.igb.0.%location: slot=0 function=0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10e8 subvendor=0x8086
subdevice=0xa02c class=0x02
dev.igb.0.%parent: pci5
dev.igb.0.nvm: -1
dev.igb.0.enable_aim: 1
dev.igb.0.fc: 65536003
dev.igb.0.rx_processing_limit: 100
dev.igb.0.link_irq: 2
dev.igb.0.dropped: 0
dev.igb.0.tx_dma_fail: 0
dev.igb.0.rx_overruns: 0
dev.igb.0.watchdog_timeouts: 0
dev.igb.0.device_control: 1086325313
dev.igb.0.rx_control: 67141634
dev.igb.0.interrupt_mask: 4
dev.igb.0.extended_int_mask: 2147483655
dev.igb.0.tx_buf_alloc: 0
dev.igb.0.rx_buf_alloc: 0
dev.igb.0.fc_high_water: 58976
dev.igb.0.fc_low_water: 58960
dev.igb.0.queue0.no_desc_avail: 0
dev.igb.0.queue0.tx_packets: 28167655
dev.igb.0.queue0.rx_packets: 942710
dev.igb.0.queue0.rx_bytes: 84905673
dev.igb.0.queue0.lro_queued: 0
dev.igb.0.queue0.lro_flushed: 0
dev.igb.0.queue1.no_desc_avail: 0
dev.igb.0.queue1.tx_packets: 27659961
dev.igb.0.queue1.rx_packets: 219218
dev.igb.0.queue1.rx_bytes: 34229378
dev.igb.0.queue1.lro_queued: 0
dev.igb.0.queue1.lro_flushed: 0
dev.igb.0.mac_stats.excess_coll: 0
dev.igb.0.mac_stats.single_coll: 0
dev.igb.0.mac_stats.multiple_coll: 0
dev.igb.0.mac_stats.late_coll: 0
dev.igb.0.mac_stats.collision_count: 0
dev.igb.0.mac_stats.symbol_errors: 0
dev.igb.0.mac_stats.sequence_errors: 0
dev.igb.0.mac_stats.defer_count: 0
dev.igb.0.mac_stats.missed_packets: 0
dev.igb.0.mac_stats.recv_no_buff: 0
dev.igb.0.mac_stats.recv_undersize: 0
dev.igb.0.mac_stats.recv_fragmented: 0
dev.igb.0.mac_stats.recv_oversize: 0
dev.igb.0.mac_stats.recv_jabber: 0
dev.igb.0.mac_stats.recv_errs: 0
dev.igb.0.mac_stats.crc_errs: 0
dev.igb.0.mac_stats.alignment_errs: 0
dev.igb.0.mac_stats.coll_ext_errs: 0
dev.igb.0.mac_stats.xon_recvd: 0
dev.igb.0.mac_stats.xon_txd: 0
dev.igb.0.mac_stats.xoff_recvd: 0
dev.igb.0.mac_stats.xoff_txd: 0
dev.igb.0.mac_stats.total_pkts_recvd: 1277070
dev.igb.0.mac_stats.good_pkts_recvd: 1161923
dev.igb.0.mac_stats.bcast_pkts_recvd: 101354
dev.igb.0.mac_stats.mcast_pkts_recvd: 714
dev.igb.0.mac_stats.rx_frames_64: 102154
dev.igb.0.mac_stats.rx_frames_65_127: 1015473
dev.igb.0.mac_stats.rx_frames_128_255: 6736
dev.igb.0.mac_stats.rx_frames_256_511: 10919
dev.igb.0.mac_stats.rx_frames_512_1023: 1719
dev.igb.0.mac_stats.rx_frames_1024_1522: 24922
dev.igb.0.mac_stats.good_octets_recvd: 123782443
dev.igb.0.mac_stats.good_octets_txd: 55500343847
dev.igb.0.mac_stats.total_pkts_txd: 55828073
dev.igb.0.mac_stats.good_pkts_txd: 55828073
dev.igb.0.mac_stats.bcast_pkts_txd: 5
dev.igb.0.mac_stats.mcast_pkts_txd: 1
dev.igb.0.mac_stats.tx_frames_64: 10267735
dev.igb.0
Re: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Okay, thanks i'll post it there.. i missed that there's also a pf-related list, sorry Has anything changed from 8.2 to 9.0 that i missed to consider in configuration? Yes, the implementation was updated ... -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: PF NAT issue with 9.0-BETA3 and RELENG_9 'head'
Florian Wilkemeyer wrote: On Tue, Oct 18, 2011 at 6:16 PM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On 18. Oct 2011, at 15:38 , Florian Wilkemeyer wrote: Hello, i recently switched a router in our test-environment to FreeBSD 9.0-Beta= 3 (and after things didnt worked ... checked out the current RELENG_9 and recompiled kernel world .. ) freebsd-pf archives might be a good start and the better list ... Okay, thanks i'll post it there.. Did you by chance, run out of state entries? I believe the work-around is to load pf as a module until the issue is fixed. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -O2 broke ppp NAT
On Fri, 2003-03-07 at 01:24, Bruce Cran wrote: On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote: On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It compiles cleanly though, but I don't know enough about gcc optimizations to find out how O2 might break it. Upon further testing (recompiling usr.sbin/ppp) with no optimizations except -O -pipe. -nat still fails to work with anything other than ICMP traffic. I'm gonna try rebuild world without -O2, but that's not gonna help trace where the problem is. :( -- Khairil Yusof [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: -O2 broke ppp NAT
On Fri, Mar 07, 2003 at 10:47:17PM +0800, Khairil Yusof wrote: On Fri, 2003-03-07 at 01:24, Bruce Cran wrote: On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote: On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It compiles cleanly though, but I don't know enough about gcc optimizations to find out how O2 might break it. Upon further testing (recompiling usr.sbin/ppp) with no optimizations except -O -pipe. -nat still fails to work with anything other than ICMP traffic. I'm gonna try rebuild world without -O2, but that's not gonna help trace where the problem is. :( I can tell you for shure that the problem is in libalias. Natd is staticaly compiled so you need to relink it, for ppp it is sufficient to just replace libalias.so. I have not recompiled the binaries but replaced them with older versions, so I can't say for shure that it depend on compiler options. Someone else already found out, that the calculated checksums are wrong. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 broke ppp NAT
On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It compiles cleanly though, but I don't know enough about gcc optimizations to find out how O2 might break it. -- Khairil Yusof [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: -O2 broke ppp NAT
On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote: On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote: For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It compiles cleanly though, but I don't know enough about gcc optimizations to find out how O2 might break it. 387 (FPU) code generation seems to be broken in gcc 3.2.1 when -O2 is used. I can compile applications with no problems when -mfpmath=sse is added so that the 387 unit won't be used, but without it, applications crash. Note that since SSE support is enabled by the kernel, it probably wouldn't be a good idea to compile the kernel with -mfpmath=sse. Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
387 FPU code (Was: Re: -O2 broke ppp NAT)
On Thu, 6 Mar 2003, Bruce Cran wrote: 387 (FPU) code generation seems to be broken in gcc 3.2.1 when -O2 is used. Would you happen to know if this is still broken in 3.2.2? I can compile applications with no problems when -mfpmath=sse is added so that the 387 unit won't be used, but without it, applications crash. Note that since SSE support is enabled by the kernel, it probably wouldn't be a good idea to compile the kernel with -mfpmath=sse. I use -O2 -pipe -mmmx -msse -mfpmath=sse to compile world and kernel. So far so good, no quirks to date! :) Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-O2 broke ppp NAT
Hello to all, For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working again. I know that this isn't a important issue or bug because there are lots of warnings about gcc optimizations because the system may become unstable. I will not use extra optitimization on my buildsi anymore. A good lesson. Thanks very much, Nuno Teixeira -- /* PGP fingerprint: C6D1 06ED EB54 A99C 6B14 6732 0A5D 810D 727D F6C6 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 broke ppp NAT
On Wed, Mar 05, 2003 at 10:00:20PM +, Nuno Teixeira wrote: I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working again. I know that this isn't a important issue or bug because there are lots of warnings about gcc optimizations because the system may become unstable. If you can isolate exactly which lines of code are failing then it may help to identify the bug (either in the FreeBSD code, or in gcc). If you're not willing/able to do that, then you've already found the solution: I will not use extra optitimization on my buildsi anymore. A good lesson. :-) Kris pgp0.pgp Description: PGP signature
libalias/NAT incremental checksum (was Re: Removal of netns)
Mark Murray wrote: How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? Terry, you sound rather foolish when you argue like this. This is semantic tomfoolery and off topic. End of thread. This is not a argument over mere implmenetation semantics. The incremental checksum code is broken. Bad tcpchecksum - before: 0x38f3 after: 0x1802 Bad tcpchecksum - before: 0x2870 after: 0xe81e Bad tcpchecksum - before: 0x6319 after: 0x0608 Bad tcpchecksum - before: 0x369a after: 0x1212 Bad tcpchecksum - before: 0xd885 after: 0x0004 The packets do not get through, no matter how many times they are resent by the sender. The reason that the CVSup is successful is an artifact of the CVSup retry mechanism. People using other protocols, like FTP, or programs like fetch are well and truly screwed by this bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC3 /etc/rc.d/ipfw natd start-up script bug -- was: 5.0-RC1/etc/rc.d/ipfw script and NAT
Is there any chance of getting the fix suggested in PR-47024 in 5.0 before release? Looks like a similar script bug with natd start-up was fixed in 4.x-STABLE back in Feb. of 2002 -- See the CVS logs for /etc/rc.network, in particular, cjc's log entries for revision 1.124 (MAIN) and revision 1.74.2.31 (RELENG_4) where this very same bug was addressed and fixed in rc.network. Thanks! Aaron out. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1 /etc/rc.d/ipfw script and NAT
Hi,
There's trouble in the /etc/rc.d/ipfw script in how it changes things
versus the 4.7 /etc/rc.network script when it comes to NAT in certain
configurations.
For example, on my home gateway box, rc.conf contains:
# Network address translation:
natd_enable=YES
natd_interface=
natd_flags=-f /etc/natd.conf
Notice that I deliberately do NOT list any interfaces because I am using
an explicit configuration file (the -f /etc/natd.conf flags). Under
4.7-STABLE, the natd daemon will be started appropriately even though
the natd_interface variable is empty, so long as natd_enable is YES
and so long as I am smart enough to have some sort of configuration
available to natd.
Under 5.0-RC1, /etc/rc.d/ipfw makes a 2-line change, moving the lines
that actually start the natd daemon up inside of an if statement. This
means folks like myself who use an explicit configuration file (i.e. I
don't run natd on any one specific interface - I run it inbound on one
interface, outbound on another using a custom ipfw ruleset and natd
configuration file) cannot have natd auto-start without changing
/etc/rc.d/ipfw or starting it by hand somewhere else.
May I request that the two lines in /etc/rc.d/ipfw that start natd be
moved down a few lines outside of the enclosing if block so that the
functionality many of us -STABLE users are accustomed to may be
returned? If not, can anyone shed some light on why it's a bad idea and
offer any suggestions to me? (I like to make as few changes to my BSD
box as possible to have it run how I want it to.)
Thanks!
Aaron out.
- NATD section of /etc/rc.d/ipfw as I would like to see it -
# Network Address Translation daemon
#
if checkyesno natd_enable; then
if [ -n ${natd_interface} ]; then
if echo ${natd_interface} | \
grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then
natd_flags=$natd_flags -a ${natd_interface}
else
natd_flags=$natd_flags -n ${natd_interface}
fi
fi
echo -n ' natd'
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: strange problem of PPPoE + NAT
the other problem i had after switch that system to -current is that after a random time, the connection will frzzed. the routing table still exist, connection is still up. just cant connect to anywhere outside the network. no error or anything been loged in ppp.log. Interestingly enough, I've been having the same problem with PPPoE ever since it hit the tree 'bout a year ago. It happens infrequently enough that I tend to blame my provider, rather than ppp. When it happens, killing ppp and restarting it is usually enough. Drop Julian or Archie a line; Julian wrote the code for netgraph for PPPoE, and Archie modified it most recently. BTW: I believe PPPoE in both Julian and Archie's cases specifically uses the netgraph PPP implementation, so it's an "all in the kernel" approach; the problem may be your use of user space code (i.e. killable code, since you can't kill it in the kernel, only unlink or unload it). Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
BTW: I believe PPPoE in both Julian and Archie's cases specifically uses the netgraph PPP implementation, so it's an "all in the kernel" approach; the problem may be your use of user space code (i.e. killable code, since you can't kill it in the kernel, only unlink or unload it). Actually, I dont believe so. At least, ppp(8) merely uses the PPPoE netgraph node, and does all PPP processing in user space, AFAICT. If, however, you're referring to mpd, then yes, that uses the netgraph PPP implementation. Terry Lambert josh -- "Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read 'The Story of O'" -- Dennis Miller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
BTW: I believe PPPoE in both Julian and Archie's cases specifically uses the netgraph PPP implementation, so it's an "all in the kernel" approach; the problem may be your use of user space code (i.e. killable code, since you can't kill it in the kernel, only unlink or unload it). Actually, I dont believe so. At least, ppp(8) merely uses the PPPoE netgraph node, and does all PPP processing in user space, AFAICT. If, however, you're referring to mpd, then yes, that uses the netgraph PPP implementation. Yes, mpd. Both Archie and Julian were running pure netgraph systems with different PPPoE cable modem provider configurations; I can't vouch for Archie's configuration, but I'm positive that Julian had it going, since he was using it at his apartment in SFO before he went back to OZ. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
thx. that fix my problem ;) the other problem i had after switch that system to -current is that after a random time, the connection will frzzed. the routing table still exist, connection is still up. just cant connect to anywhere outside the network. no error or anything been loged in ppp.log. the connection just simply freezed. the only way to bring the connection back is to reboot the system. (i try to just bring down the interface and bring back up. but it seems doesnt help), otherwise it will give an error of unable to connect to device.. at the moment, everytime i run ppp, follow error will appear module_register: module netgraph already exists! linker_file_sysinit "netgraph.ko" failed to register! 17 but i believe this has nothing to do with the problem connection freezed. plz help! On Sat, 21 Oct 2000, Josh Tiefenbach wrote: On Sat, Oct 21, 2000 at 11:08:28PM +1000, Idea Receiver wrote: I just upgrade one of my server to -current. that server connect to ADSL and act as a gateway. however, after I upgrade that server to -current, all other clients (all windows 98) start acting really strange. clients was unable to connect to more then 60% of web sites. for example, clients can not Sounds like a PMTU-D problem. Either change the MTU of the machines behind the gateway to something like 1440, or try /usr/ports/net/tcpmssd. josh -- "Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read 'The Story of O'" -- Dennis Miller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
the other problem i had after switch that system to -current is that after a random time, the connection will frzzed. the routing table still exist, connection is still up. just cant connect to anywhere outside the network. no error or anything been loged in ppp.log. Interestingly enough, I've been having the same problem with PPPoE ever since it hit the tree 'bout a year ago. It happens infrequently enough that I tend to blame my provider, rather than ppp. When it happens, killing ppp and restarting it is usually enough. I have no idea what causes it. module_register: module netgraph already exists! linker_file_sysinit "netgraph.ko" failed to register! 17 Just a guess, but thats probably because you're trying to kldload netgraph.ko, but have already compiled it into your kernel with options NETGRAPH josh -- "Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read 'The Story of O'" -- Dennis Miller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
On Wed, 25 Oct 2000, Josh Tiefenbach wrote: Interestingly enough, I've been having the same problem with PPPoE ever since it hit the tree 'bout a year ago. It happens infrequently enough that I tend to blame my provider, rather than ppp. When it happens, killing ppp and restarting it is usually enough. I have no idea what causes it. kill ppp and restart it doesnt help at all. will it make any different if i change a network card? it happen so frequently, it is impossible to run a stable server with PPPoE! module_register: module netgraph already exists! linker_file_sysinit "netgraph.ko" failed to register! 17 Just a guess, but thats probably because you're trying to kldload netgraph.ko, but have already compiled it into your kernel with options NETGRAPH nope. i didnt kldload netgraph.ko at all. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
When it happens, killing ppp and restarting it is usually enough. I have no idea what causes it. kill ppp and restart it doesnt help at all. will it make any different if i change a network card? I dont think so. There are times when I cant do a simple kill/restart, and I have to physically shut off the modem, cycle power on my server, and bring it up again. While this *may* be a function of the PPPoE code, I'm inclined to blame my provider, if only because they've had issues in the past. I presently lack the resources to adequately debug the issue. it happen so frequently, it is impossible to run a stable server with PPPoE! Might I suggest you drop a note over on freebsd-net? Perhaps you'll rustle up some more support there. josh -- "Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read 'The Story of O'" -- Dennis Miller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange problem of PPPoE + NAT
On Sat, Oct 21, 2000 at 11:08:28PM +1000, Idea Receiver wrote: I just upgrade one of my server to -current. that server connect to ADSL and act as a gateway. however, after I upgrade that server to -current, all other clients (all windows 98) start acting really strange. clients was unable to connect to more then 60% of web sites. for example, clients can not Sounds like a PMTU-D problem. Either change the MTU of the machines behind the gateway to something like 1440, or try /usr/ports/net/tcpmssd. josh -- "Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read 'The Story of O'" -- Dennis Miller To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NAT tutorial?
Does anyone know of a tutorial or more detailed instructions on how to use NAT and IP masquerading in 3.4? I can configure it so that it is running and working with IP firewall within the box no problem, but as far as dolling out local IPs to the rest of the workstations or even building a natd.conf file, I'm lost. The closest I've found is the tutorial at http://freebsd.peon.net, but that doesn't quite cover enough. Thanks in advance, Jason Mitchell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NAT tutorial?
Hi Jason, This is really a -questions question, not a -current question. On Wed, 26 Apr 2000, Jason Mitchell wrote: Does anyone know of a tutorial or more detailed instructions on how to use NAT and IP masquerading in 3.4? "IP masquerading" is what the linux people call NAT. They are the same thing. I can configure it so that it is running and working with IP firewall within the box no problem, but as far as dolling out local IPs to the rest of the workstations Dynamic allocation of IP addresses to workstations doesn't have much to do with NAT -- try hunting for information on dhcp or bootp. There are two DHCP servers in the ports tree (net/isc-dhcp2 and net/wide-dhcp). If I'm barking up the wrong tree, and you're actually talking about static NAT maps, then see natd(8). or even building a natd.conf file, I'm lost. You have read natd(8), right? The closest I've found is the tutorial at http://freebsd.peon.net, but that doesn't quite cover enough. Try describing exactly what you're trying to achieve, rather than guessing at components that might provide solutions -- then post the question to the -questions list. There are lots of helpful people there that will give you ideas. Oh -- also, check out Dan's list of NAT articles at http://www.freebsddiary.org/topics.php3#nat Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ppp / nat pptp
[ Please redirect me to a better mailinglist if needed, I haven't had any replies on this subject yet ] I'm getting closer. Basically, I have at home a win-machine behind a FreeBSD box with user-ppp and isdn. It is cheaper for me to use an alternative ISP than ourselves to get the machines at work. However, then I don't have access to some servers, because I come from a foreign (and dynamic) ip-adress. So I install pptpd on a machine at work to make a tunnel and get a "trusted" ip-adress. Questions: man ppp, topic nat pptp suggest, that only one machine behind ppp can run MS-vpn (over GRE). True? Is it a problem that I only have one ethernet card on the pptpd-machine: am I supposed to go in on one interface, be translated, and go out on the other? Any clues on setting up pptpd and ppp? It seems that the adresses (localip and remoip) in pptpd.conf are ignored, and the adresses in ppp.conf are used instead. Currently, I can now connect from ms-vpn, and from the box running nntpd ping the ip on the win-box. But then I can't ping from any other adresses. Can I find some examples of poptop/pptpd and user-ppp somewhere? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NAT speed?
Did anyone make any kind of benchmarking on the NAT? I am interested in number of connections per hour / total simultaneous connections and any other perfomance related experience you may have had with it? if you intend to work on this, for measurement criteria, you may want to look at draft-ietf-bmwg-secperf-08.txt. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NAT speed?
Did anyone make any kind of benchmarking on the NAT? I am interested in number of connections per hour / total simultaneous connections and any other perfomance related experience you may have had with it? Any1? --Ugen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NAT
Hi! Is there any limit for open NAT connections? If it is where it can be set/change? Thanks, -pal To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
