Ok, I managed to cause it again.
dhclient was the problem.
My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3
setting.
When compiled with -O3 it will generate packets with bad checksums.
Simply recompiling it with -O2 did not cause this issue and dhclient
works fine.
So th
OK, so I installed a different PE1750 with BETA2 and then updated the
source via cvsup RELENG_7 from cvsup3 and all is ok now on that box.
Went back the first box and cvsup'ed the src again into an empty
directory and it compiled and worked fine. Looks like my updating of the
source along the w
Jonathan Feally wrote:
I will try another em card in that server to confirm/rule out the nic
driver. I am seeing the same checksum number on both the source
machine, the dhcp server machine, and a 3rd windows xp machine
sniffing the traffic with etherreal/wireshark. The windows xp box is
ny problems lately, but none involved checksum nor the dhcpd
(btw, I assume that you are seeing bad checksum on the receiving server)
could you add a nic to your PE1750?
danny
Jonathan Feally wrote:
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes runn
Can someone please confirm or rule out my issue with dhclient sending
bad IP checksum packets. It would really suck if 7.1 was released with a
broken DHCP client.
Jonathan Feally wrote:
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes running 7-STABLE as of
Sorry for the cross-post, but this could be either lists problem.
I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is
running ISC DHCPD 3.0.x from recent ports, and the other dhclient from
make world.
The server is refusing to answer the DISCOVER request, as it thinks the
I
1:04 -0800, Jonathan Feally <[EMAIL PROTECTED]> wrote:
Sorry to cross post, but the net list didn't help a couple weeks back on
this.
names, natd, and dhcpd have all been getting stuck in zoneli (zone
limit) since I upgraded to the box to stable about a month ago. It was
running a 6.1-S
Sorry to cross post, but the net list didn't help a couple weeks back on
this.
names, natd, and dhcpd have all been getting stuck in zoneli (zone
limit) since I upgraded to the box to stable about a month ago. It was
running a 6.1-STABLE before with out difficulty. Very little has changed
on
ly since I'm running what is going to be 6.2-RELEASE.
Looking back at the mailing list - I see that there was a change to
ipfw.c that deals with dynamic rule timeout, perhaps this is to blame?
I am willing to give ssh access to debug this problem.
-Jon
Robert Watson wrote:
On Fri, 13
Hello,
I have a P4 2.8 box running on an intel MB with a em0 acting as a firewall.
The em0 has multiple tagged vlans on it, no ip assigned to main interface.
Almost clockwork now, 6-7 days after bootup named or dhcpd completly
locks up. I can't even kill -9 the apps.
I have recompiled both apps
Why whould you want to use that kernel option? I don't see that it is a
requirement on the blade how-to. My guess is you haven't specifically
set the interface to a media speed and duplex as the option indicates to
me that the driver would not attempt auto negotiation. If the option is
not requ
ure things are working
with changing the vlan mac's.
-Jon
Jonathan Feally wrote:
Good to know about the mtu, however I'm still having the same problem
with a Pro/1000 em0. I have only tagged vlans running on em0 and the
admin vlan (1) running untagged on bge0. The only 2 networks in p
Good to know about the mtu, however I'm still having the same problem
with a Pro/1000 em0. I have only tagged vlans running on em0 and the
admin vlan (1) running untagged on bge0. The only 2 networks in play are
900 and 902. I'm not even working on packets from the lans passing
through yet. Jus
:
options IPFIREWALL
options IPFIREWALL_FORWARD
options IPFIREWALL_FORWARD_EXTENDED
options IPFIREWALL_DEFAULT_TO_ACCEPT
options DUMMYNET
options IPDIVERT
options IPSTEALTH# Tried with sysctl set to on and off.
options FAST_IPSEC
device crypto
Help Thanks, -Jon
Jonathan Feally wrote
Hello,
I have setup a new firewall and I'm having trouble with it. Perhaps the
bge is to blame, perhaps its something else.
I'll explain my setup, problem and the workaround to get it going.
Box connects to 2 Internal Lans and 2 External Wans.
Vlans are mixed untagged and tagged on a single bg
ICAST
options: RXCSUM, TXCSUM, VLAN_MTU, POLLING
vlan199 flags UP, BROADCAST, RUNNING, PROMISC, SIMPLEX, MULTICAST
vlan199 has no options.
Anybody else run into this problem? I am running 5-STABLE as of today.
-Jon
Jonathan Feally wrote:
I'm trying to setup a machine that will be bo
I'm trying to setup a machine that will be both routing traffic and
bridging 2 segments of one network with ipfw processing on that bridged
network. The routing seems to be OK and bridging is also OK from Side to
side, however when trying to talk to the IP of the machine from another
machine on
Your problem lies in that vpnc is opening a raw socket to get it's ESP
packets. However when you enable esp in the kernel, the kernel already
is taking those packets, so you get the SOCK_RAW error as vpnc cannot
get ESP packets because the kernel is handling them.
I do not know if options FAST
You need to compile a custom kernel with as a minimum
options IPFIREWALL # puts ipfw statically into kernel
options IPDIVERT # see divert Disable - this will enable it
which is required for divert rule and natd
You may also want this options
options IPFIREWALL_FORWARD #en
I don't see why do you have 2 FreeBSD Boxes running as bridges. The only
reason I could possibly imagine, is that you are using IPFW or IPFilter
to do some packet filtering.
Now with vrrp, each router would have a unique IP and only one of the
routers would have the shared IP at any given time
Your problem lies in that you are counting the traffic twice in the
queue/pipe - once from the internal addr to the dst, and once from the
external addr to the dst. Change your rules to specify which IP Block
should get the bw limiting.
I don't know if the keep-state thing is throwing it out of
I have a similar setup from my home (FreeBSD) to my work (PIX-515)
10/8 is my work 192.168.X.0/24 is my home - this setup will give you
3des encrypt tunnel with a Pre-Shared Key
Your PIX will need these config lines(adjust to match your networks):
access-list ipsec-ok-list permit ip 10.0.0.0 255.
When monitoring a network, your monitoring interface should have no IP
set or an IP address that matches you network with a netmask of
255.255.255.255 if your monitoring software will not work with out an IP.
Example:
LAN is 192.168.1.0/24(255.255.255.0)
fxp0 is 192.168.1.2/24(255.255.255.0)
rl0
Has anyone come across a daemon that will translate dns query responses
from inside ip's to outside ip's, when the query is though the firewall?
The CISCO PIX I have at work does this with the alias command - but -
I'm not at work where I'd like to do that.
Thanks - Jonathan
To Unsubscribe: se
Also - In your second line for ipfw you have the syntax wrong
to divert all ip traffic to divert port 5050
ipfw add 1000 divert 5050 ip from any to any
where 1000 is the rule # - you may omit the # if you want it to get a
rule # automatically - not recomended when other rules are in use!
lower rul
You will also need
optionsIPDIVERT
in your kernel config
Martin Stiemerling wrote:
Am Montag den, 9. Dezember 2002, um 18:18, schrieb soheil soheil:
Dear ALL
i run this commands on my 4.4FreeBSD-Release
Do you have this line in your kernel configuration file and compiled
into the ke
As I think about it, it isn't IPSEC that needs to process twice once
before and once after ipfw. Its the other way around.
IPFW should first allow the ESP packets into the machine, then IPSEC
extracted the secured packet, and then IPFW will process the normal
packet again, thus allowing the dive
I was just looking at the latest postings from the net list and was
reading yours when I found this e-mail you sent directly to me.
I've had some success with IPSEC/IPFW and NATD.
The problem lies in the kernel, ipsec and ipfw ordering of where the
packets flow.
What you are trying to do - makes
On a side note:
For whoever tackles this project - a sysctl variable would be nice to
turn the second ipsec processing(pre ipfw/ipf) on or off.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Is it not possible to have the internal ip addresses of the tunnel
machines talk with other internal addresses on the other side of the tunnel?
Example Set Up:
Packets from say 192.168.0.2 to 192.168.1.1 and back
(192.168.0.0/24 Lan)-(192.168.0.1 Internal)->(200.0.0.1
Interface)===IPSEC TUNNEL==
Network setup:
Networks
Inside Net - 192
Outside Net - 63 - Natd from 192 to 63 and back
Server Net - 216
I have a esp transport IPSec policy setup from my outside IP(63) to a
server on the Internet(216) and back.
Machines on the 192 go though the natd on the outside interface and get
translated
31 matches
Mail list logo
