Artem Viklenko via freebsd-net wrote:
> >>
> >>> pass in quick on $int_if inet proto tcp from $server to any flags S/SA
> >>> keep
> >>> state allow-opts tag SERVER
> >>
> >> 2.
> >>
> >>> block return-rst out log quick on $mob_if inet proto tcp to any port 25
> >>> tagged SERVER
> >>
> >> You
On 04.04.19 08:22, Artem Viklenko via freebsd-net wrote:
04.04.19 07:30, Victor Sudakov пише:
1.
pass in quick on $int_if inet proto tcp from $server to any flags S/SA keep
state allow-opts tag SERVER
2.
block return-rst out log quick on $mob_if inet proto tcp to any port 25
tagged SERVER
04.04.19 07:30, Victor Sudakov пише:
1.
pass in quick on $int_if inet proto tcp from $server to any flags S/SA keep
state allow-opts tag SERVER
2.
block return-rst out log quick on $mob_if inet proto tcp to any port 25 tagged
SERVER
You have already passed the packet with "quick" in th
Artem Viklenko via freebsd-net wrote:
> >>>
> >>> I'm trying to migrate some firewall rules from ipfw to pf. As pf does
> >>> NAT first and filtering after NAT, I have a problem doing the following:
> >>>
> >>> 1. All 192.168.0.0/16 addresses should be translated to the real IP of
> >>> the externa
Hi!
On 02.04.19 10:03, Victor Sudakov wrote:
Sergey Akhmatov wrote:
I'm trying to migrate some firewall rules from ipfw to pf. As pf does
NAT first and filtering after NAT, I have a problem doing the following:
1. All 192.168.0.0/16 addresses should be translated to the real IP of
the externa
Sergey Akhmatov wrote:
> >
> > I'm trying to migrate some firewall rules from ipfw to pf. As pf does
> > NAT first and filtering after NAT, I have a problem doing the following:
> >
> > 1. All 192.168.0.0/16 addresses should be translated to the real IP of
> > the external interface.
> >
> > 2.
Hello, Victor.
Try using "no nat".
table {8.8.8.8, . }
nat pass on $ext_if from 192.168.3.0/24 to -> $(ext_if)
no nat on ext_if from 192.168.3.0/24 to any
nat pass on $ext_if from 192.168.0.0/16 to any -> $(ext_if)
On 01/04/2019 06:34, Victor Sudakov wrote:
Dear Colleagues,
I'm trying t
17.12.2017 17:59, Sami Halabi wrote:
> Hi Eugene,
> I'm looking for a solution for IP traffic. in linux iptables its possible but
> I couldn't find freebsd way yet.
> bkuncr soulution works for tcp only.
Then, you need to realize that for every packet, you need to change (translate)
both of sour
Hi Eugene,
I'm looking for a solution for IP traffic. in linux iptables its possible
but I couldn't find freebsd way yet.
bkuncr soulution works for tcp only.
Thanks for the hint though,
Sami
בתאריך 17 בדצמ׳ 2017 11:29 AM, "Eugene Grosbein" כתב:
> 17.12.2017 14:52, Sami Halabi пишет:
> > hi,
17.12.2017 14:52, Sami Halabi пишет:
> hi,
>
> Can you help in my situation? My goal is so Box in my lan 10.1.1.2 to talk
> to 10.1.1.1 and actually it would be talking to X.X.X.X outside ip using
> one of my public IPs say 1.1.1.1.
If you need this just for single or several tcp ports, easiest w
Bezüglich Andrey V. Elsukov's Nachricht vom 12.09.2017 15:38 (localtime):
> On 12.09.2017 16:35, Andrey V. Elsukov wrote:
>>> Either add E1000_DEV_ID_I350_COPPER_NOEE elsewhere, or try without _NOEE
>>> appendix if datasheet suggests.
>>
>> Hi,
>>
>> just defining device id in the header usually do
On 12.09.2017 16:35, Andrey V. Elsukov wrote:
>> Either add E1000_DEV_ID_I350_COPPER_NOEE elsewhere, or try without _NOEE
>> appendix if datasheet suggests.
>
> Hi,
>
> just defining device id in the header usually doesn't automatically add
> support for this device. You need to teach probe funct
On 12.09.2017 16:32, Harry Schmalzbauer wrote:
>> ===
>> --- sys/dev/e1000/e1000_hw.h(Revision 322342)
>> +++ sys/dev/e1000/e1000_hw.h(Arbeitskopie)
>> @@ -168,6 +168,7 @@
>> #define E1000_DEV_ID_82580_COPPER_DUAL 0x15
Bezüglich Harry Schmalzbauer's Nachricht vom 12.09.2017 15:23 (localtime):
> Bezüglich Igor V. Ruzanov's Nachricht vom 12.09.2017 11:00 (localtime):
>> Hello, FreeBSD colleagues!
>> Trying to forward my question to freebsd-net@ group, meybe there is a
>> chance to dig the answer
>>
>> I have mode
Bezüglich Igor V. Ruzanov's Nachricht vom 12.09.2017 11:00 (localtime):
> Hello, FreeBSD colleagues!
> Trying to forward my question to freebsd-net@ group, meybe there is a
> chance to dig the answer
>
> I have modern network card Intel i350T2V2 (peripheral dual gigabit
> port NIC). And as far as
wrote
in :
Ha> To answer my own question :-) These strange link local addresses are
Ha> explained in the developers handbook section 8.1.1.3 and are called
Ha> embedded
Ha> link local addresses. These are not standard IPv6 addresses, but a way
Ha> to encode the interface index (aka zone index)
To answer my own question :-) These strange link local addresses are explained
in the developers handbook section 8.1.1.3 and are called embedded
link local addresses. These are not standard IPv6 addresses, but a way to
encode the interface index (aka zone index) into the IPv6 address. This must
OK I'll do that.
Thanks, I appreciate the very generous offer. :-)
Cheers
Kip Macy <[EMAIL PROTECTED]> wrote:
Sam is really busy right now (I am too :-( ). If someone hasn't gotten
to it in a week ping me again and I will try to fix it. I need to set
up a RELENG_6 install this
On 2/27/07, Vincent Howell <[EMAIL PROTECTED]> wrote:
I'm using MFC'd one for RELENG_6:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/ndis/subr_ntoskrnl.c?rev=1.71.2.6&content-type=text/x-cvsweb-markup&sortby=date
I was getting more "missing feature" errors before trying the patch a
I'm using MFC'd one for RELENG_6:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/ndis/subr_ntoskrnl.c?rev=1.71.2.6&content-type=text/x-cvsweb-markup&sortby=date
I was getting more "missing feature" errors before trying the patch and
upgrading to 6.2-STABLE.
I've tried a half
Sam Leffler recently added a new entry in -CURRENT for the part. I
think the change needs to MFC'd. Perhaps someone (Max?) could do that.
-Kip
On 2/25/07, Vincent Howell <[EMAIL PROTECTED]> wrote:
Hello,
I'm trying to get my Broadcom (BCM43XX-based) WNIC working in FreeBSD 6.2 but
am un
You can google it, there're many articles.
Breifly answer your question:
1. Compile kernel to support ipfw (firewall).
2. Edit /etc/sysctl.conf add "net.inet.ip.forwarding=1" for routing.
Good luck.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of angelito m
I've done this on ciscos but not on FBSD. There is probably a couple of good ways to
do this. I think this will work (criticism welcome).
Given that you have a network 1.2.3.176/29 (8 addresses, 6 hosts), and your ISP has
given you a gateway address of 1.2.4.239/30 for your external interface..
On Tue, 2003-09-02 at 22:45, Philip Kizer wrote:
> Donald Burr of Borg <[EMAIL PROTECTED]> wrote:
> [Description of:]
> >Our gateway machine and server gets its own IP, IP A.
> >My desktop machine is hooked up via ethernet. It should get IP B.
> >Same thing as above for my roomie's de
Donald Burr of Borg <[EMAIL PROTECTED]> wrote:
[Description of:]
>Our gateway machine and server gets its own IP, IP A.
>My desktop machine is hooked up via ethernet. It should get IP B.
>Same thing as above for my roomie's desktop, except it gets IP C.
>[all else] Ideally I'd like t
>
> Ok, I am now armed with quite a bit more info regarding these attacks.
>
> First off, the target looks like this:
>
> Port State Service
> 21/tcp openftp
> 22/tcp openssh
> 25/tcp opensmtp
> 53/tcp opendomain
> 80/tcp open
>
> Hello,
>
> Ok, right now this second, everything is normal, I am not under attack
> AFAIK, and everything is working wonderfully - and when I run top I see:
>
> 21 processes: 1 running, 20 sleeping
> CPU states: 0.0% user, 0.0% nice, 0.0% system, 41.7% interrupt, 58.3%
> idle
> Mem: 6812
Alternatively, is getting a much faster CPU (p3 1.6g ?) a "big hammer"
that solves problems related to the number of rules being parsed for each
packet ?
Just curious.
On Sun, 5 Jan 2003, Barney Wolff wrote:
> On Sun, Jan 05, 2003 at 01:31:24PM -0800, Josh Brooks wrote:
> > So, I have 927 ipfw
On Sun, Jan 05, 2003 at 01:31:24PM -0800, Josh Brooks wrote:
> So, I have 927 ipfw tules in place - but I am guessing that about 800 of
> those rules are just "count" rules for me to count bandwidth:
>
> 001 164994 120444282 count ip from any to 10.10.10.10
> 002 158400 16937232 count ip from 10.1
Ok, I am now armed with quite a bit more info regarding these attacks.
First off, the target looks like this:
Port State Service
21/tcp openftp
22/tcp openssh
25/tcp opensmtp
53/tcp opendomain
80/tcp openhttp
110/tcpopen
Hello,
Ok, right now this second, everything is normal, I am not under attack
AFAIK, and everything is working wonderfully - and when I run top I see:
21 processes: 1 running, 20 sleeping
CPU states: 0.0% user, 0.0% nice, 0.0% system, 41.7% interrupt, 58.3%
idle
Mem: 6812K Active, 43M Inact,
On 1/5/2003 1:05 PM, Josh Brooks wrote:
I am running this as my firewall/router:
4.4-RELEASE FreeBSD 4.4-RELEASE #0
And I have no ability to change that anytime soon. Recently I have been
having a lot of trouble with floods/ddos/etc. When these attacks occur,
my firewall is totally unresponsi
gment
retransmissions. That, I believe, indicates a healthy network.
Any other ideas?
Thank you,
Arkadi.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Vermillion
> Sent: Wednesday, April 10, 2002 11:18 PM
> To: [EMAIL PROTECTED]
> Su
On Wed, Apr 10, 2002 at 11:06:09PM +1000, Arkadi Kosmynin spewed forth:
> I really can not explain this. We are stress testing a server. We
> use the following configuration: the server runs on a FreeBSD box
> (or Linux, with a similar effect). A multithreaded tester program
> runs on a Win2K box
> The UDP "dropped due to full socket buffers" increases with time
This is on the receiving machine, right? It looks like the application
isn't reading the buffer. Do a 'ps l' on the application and look at the
WCHAN to see if the application is running or waiting for something.
To Unsubscr
On Thu, 31 Jan 2002, Jeffrey Hsu wrote:
> What does netstat -s say?
It looks as if it gets progressively worse over time.
The UDP "dropped due to full socket buffers" increases with time:
[NOTE]: tcpdump on the wire reveals that packets are still being sent
back to the NAS. I have a trace if
What does netstat -s say?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Wed, 30 Jan 2002, Naga R Narayanaswamy wrote:
> Nick Rogness wrote:
> Which radius server package are you using. Because I know there are
> different
> port packages for radius server.
Radiator.
> After how long (days or hours) did you encounter this problem?
>
It's random.
Nick Rogness wrote:
Which radius server package are you using. Because I know there are
different
port packages for radius server.
After how long (days or hours) did you encounter this problem?
Don't you have some sort of logging on the server. I usually turn on
some level of debug, which gives
On Wed, 30 Jan 2002, Nick Rogness wrote:
>
> Our Radius server seems to stop functioning after a while. netstat
> -an reports:
>
> Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
>
> [SNIP]
> udp4 0 0 *.1646
Well, if ipfw cann't do the work, you can check out
ipfilter module as well. It's a bit different in nat
code.
==
WWW.XGFORCE.COM
The Next Generation Load Balance and
Fail Safe Server Clustering Software
for the Internet.
==
41 matches
Mail list logo