Re: pf block unwanted traffic
Hello List,
I just got a similar event in my pflog.
Jan 16 16:08:02.435283 rule def/(short) pass in on pppoe0: 50.112.59.10.0 >
59.167.212.41.0: SFRWE [bad hdr length]
I don't know what this is, or why it is passed.
Can someone explain or attempt a guess at what this is?
The intention of my pf.conf is to block all incoming
by default on pppoe0.
Am I doing something really stupid here?
/etc/hostname.carp1
inet 172.75.100.1 255.255.255.0 172.25.101.255 balancing ip-stealth carpnodes
1:0,2:100 pass secret1
group dmz
/etc/hostname.carp2
inet 172.25.100.1 255.255.255.0 172.25.100.255 balancing ip-stealth carpnodes
4:0,5:100 pass secret2
group lan
/etc/hostname.em0
up mtu 1508
/etc/hostname.em1
inet 172.75.100.4 255.255.255.0
group dmz
/etc/hostname.em2
inet 172.25.100.4 255.255.255.0
group lan
/etc/hostname.pppoe0
inet 59.167.212.41 255.255.255.255 NONE mtu 1500 \
pppoedev em0 authproto pap \
authname pppoeuser authkey pppoepass up
dest 0.0.0.1
!/sbin/route add default -ifp pppoe0 0.0.0.1
!/sbin/route add -inet6 default -ifp pppoe0 ::1
/etc/pf.conf
#---
# defaults
#---
table const { 192.168/16 172.16/12 10/8 }
table const { dmz:network }
table const { lan:network }
set loginterface egress
set skip on lo
block in quick on egress from
antispoof log quick for { pppoe0 em0 }
pass
block quick on egress proto carp
block quick on { egress dmz } inet6
block in log on { egress dmz }
#---
# ack priority
#---
match on egress inet proto tcp prio(1,7)
#---
# sand blasting
#---
match in on egress scrub (reassemble tcp)
#match in on { egress dmz } scrub (reassemble tcp)
#match on egress scrub (max-mss 1440)
#---
# translation and redirections
#---
match out on egress nat-to (egress)
match in on { lan dmz } inet proto tcp to ! bincrow.net \
port www rdr-to localhost port 8080
match in on { lan dmz } inet proto tcp to bincrow.net \
port www rdr-to localhost
match in on { lan dmz } inet to bincrow.net rdr-to localhost
#---
# incoming port forwards
#---
# torrent
pass in on egress inet proto tcp to egress port 6881 rdr-to meile \
modulate state
pass in on egress inet proto udp to egress port 6881 rdr-to meile \
keep state
#---
# allow anyone to this
#---
pass in on egress inet proto tcp from any to egress port www \
modulate state
#---
# dns
#---
table persist file "/etc/pf/dns-white"
pass in on egress inet proto { tcp udp } from \
to egress port domain
pass in on dmz inet proto { tcp udp } from \
to dmz port domain
#---
# ntp
#---
pass in on dmz inet proto { tcp udp } from \
to dmz port { daytime time ntp }
#---
# ssh - whitelist, and rate limit overflows into blacklist
#---
table persist file "/etc/pf/ssh-black"
table persist file "/etc/pf/ssh-white"
pass in log on { egress dmz } inet proto tcp from to \
port ssh rdr-to localhost
pass in log on { egress dmz } inet proto tcp from ! to \
port ssh rdr-to localhost keep state \
(max-src-conn-rate 1/30, overload flush)
#---
# imaps - whitelist, and rate limit overflows into blacklist
#---
table persist file "/etc/pf/imaps-black"
table persist file "/etc/pf/imaps-white"
pass in log on { egress dmz } inet proto tcp from to \
port imaps rdr-to localhost
pass in log on { egress dmz } inet proto tcp from ! to \
port imaps rdr-to localhost keep state \
(max-src-conn-rate 2/1, overload flush)
#---
# squid - whitelist
#---
table persist file "/etc/pf/squid-white"
pass in on egress inet proto
Re: Routing confusion?
On 2013-01-15, Johan Helsingius wrote: > Peter, > >> :em0 (internal network): >> :inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 >> :em2 (wifi sandbox): >> :inet 172.24.42.223 netmask 0xffc0 broadcast 172.24.42.255 >> : >> >> You can't do that. > > What specific reason is there that that won't work? $ ipcalc 172.24.42.223/0xffc0 address : 172.24.42.223 netmask : 255.255.255.192 (0xffc0) network : 172.24.42.192 /26 broadcast : 172.24.42.255 host min : 172.24.42.193 host max : 172.24.42.254 hosts/net : 62 The 172.24.42.254 address you have on em0 is *inside* the 172.24.42.192/26 network you have on em2. You would need to move that to another address that is in the /24 but outside the /26. Additionally you would need to add a static route on the machines in em0's network so that 172.24.42.192/26 is routed to whatever new address you have for em0 as you have to consider the return path as well as the forward path. Basically: supernetting is tricky, it's best avoided unless there's no other choice - even if you are pretty familiar with networking it's easy to get wrong.
Re: I need a little more Enlightenment
On Tue, 15 Jan 2013 11:33:54 +0100, Stefan Sperling wrote: >On Tue, Jan 15, 2013 at 04:35:24PM +1100, Rod Whitworth wrote: >> E installs without whining. >> >> I changed xinitrc to remove the icewm setting and added:- >> exec enlightenment_start >> >> startx gives a very dark screen and a mouse cursor pops up in the >> centre. Then the screen has a short flash of white all over before the >> dark screen comes back without the mouse cursor. > >Hmmm... no idea what the problem could be. Sounds like the X server >is crashing. Please show /var/log/Xorg.0.log, too. Here it is: = [ 206.914] (--) checkDevMem: using aperture driver /dev/xf86 [ 206.927] (--) Using wscons driver on /dev/ttyC4 in pcvt compatibility mode (version 3.32) [ 208.018] X.Org X Server 1.12.2 Release Date: 2012-05-29 [ 208.018] X Protocol Version 11, Revision 0 [ 208.018] Build Operating System: OpenBSD 5.2 i386 [ 208.018] Current Operating System: OpenBSD red.witworx.com 5.2 GENERIC.MP#339 i386 [ 208.018] Build Date: 22 July 2012 10:21:16PM [ 208.018] [ 208.018] Current version of pixman: 0.24.4 [ 208.019]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 208.019] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 208.019] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 16 10:12:12 2013 [ 208.074] (==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d" [ 208.083] (==) No Layout section. Using the first Screen section. [ 208.084] (==) No screen section available. Using defaults. [ 208.084] (**) |-->Screen "Default Screen Section" (0) [ 208.084] (**) | |-->Monitor "" [ 208.084] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 208.084] (==) Disabling SIGIO handlers for input devices [ 208.084] (==) Automatically adding devices [ 208.084] (==) Automatically enabling devices [ 208.249] (==) FontPath set to: /usr/X11R6/lib/X11/fonts/misc/, /usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/OTF/, /usr/X11R6/lib/X11/fonts/Type1/, /usr/X11R6/lib/X11/fonts/100dpi/, /usr/X11R6/lib/X11/fonts/75dpi/ [ 208.249] (==) ModulePath set to "/usr/X11R6/lib/modules" [ 208.249] (II) The server relies on wscons to provide the list of input devices. If no devices become available, reconfigure wscons or disable AutoAddDevices. [ 208.261] (II) Loader magic: 0x3c021020 [ 208.261] (II) Module ABI versions: [ 208.261]X.Org ANSI C Emulation: 0.4 [ 208.261]X.Org Video Driver: 12.0 [ 208.261]X.Org XInput driver : 16.0 [ 208.261]X.Org Server Extension : 6.0 [ 208.263] (--) PCI:*(0:0:2:0) 8086:0126:17aa:21ee rev 9, Mem @ 0xd000/4194304, 0xc000/268435456, I/O @ 0x4000/64 [ 208.263] (II) LoadModule: "extmod" [ 208.291] (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.so [ 208.301] (II) Module extmod: vendor="X.Org Foundation" [ 208.301]compiled for 1.12.2, module version = 1.0.0 [ 208.301]Module class: X.Org Server Extension [ 208.301]ABI class: X.Org Server Extension, version 6.0 [ 208.301] (II) Loading extension MIT-SCREEN-SAVER [ 208.301] (II) Loading extension XFree86-VidModeExtension [ 208.301] (II) Loading extension XFree86-DGA [ 208.301] (II) Loading extension DPMS [ 208.301] (II) Loading extension XVideo [ 208.301] (II) Loading extension XVideo-MotionCompensation [ 208.301] (II) Loading extension X-Resource [ 208.301] (II) LoadModule: "dbe" [ 208.302] (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.so [ 208.309] (II) Module dbe: vendor="X.Org Foundation" [ 208.309]compiled for 1.12.2, module version = 1.0.0 [ 208.309]Module class: X.Org Server Extension [ 208.309]ABI class: X.Org Server Extension, version 6.0 [ 208.309] (II) Loading extension DOUBLE-BUFFER [ 208.309] (II) LoadModule: "glx" [ 208.309] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so [ 208.320] (II) Module glx: vendor="X.Org Foundation" [ 208.320]compiled for 1.12.2, module version = 1.0.0 [ 208.320]ABI class: X.Org Server Extension, version 6.0 [ 208.320] (==) AIGLX enabled [ 208.321] (II) Loading extension GLX [ 208.321] (II) LoadModule: "record" [ 208.321] (II) Loading /usr/X11R6/lib/modules/extensions/librecord.so [ 208.322] (II) Module record: vendor="X.Org Foundation" [ 208.322]compiled for 1.12.2, module version = 1.13.0 [ 208.322]Module class: X.Org Server Extension [ 208.322]ABI class: X.Org Server Extension, version 6.0 [ 208.322] (II) Loading extension RECORD [ 208.322] (II) LoadModule: "dri" [ 208.322] (II) Loading /usr/X11R6/lib/modules/extensions/libdri.so [ 208.344] (II) Module dri: vendor="X.Org Fou
Re: snapshots total freeze (linux emulation)
On Fri, Dec 28, 2012 at 1:07 PM, Philip Guenther wrote: > On Fri, Dec 28, 2012 at 8:57 AM, frantisek holop wrote: ... >> savecore came on and i have in the logs: >> >> Dec 28 00:25:25 amaaq savecore: reboot after panic: kernel diagnostic >> assertion "wp->wp_new_futex == f" failed: file >> "../../../../compat/linux/linux_futex.c", line 568 > > Excellent. The next question is whether that's the only bug that > you're hitting, or if there's something else going on that should also > be debugged. > > As for that particular failed assertion, it would be interesting to > know what the actual values of wp->wp_mew_futex was (if it was NULL, > then I have a guess as to the bug; if it wasn't NULL, then uh, good > luck!) The fix for this has been committed, at least if it's the wp->wp_new_futex==NULL case. Philip Guenther
OSPFD on a VLAN Trunk Interface
Hi,
I am having some trouble getting ospfd working as I would like it.
1) I have a VLAN trunk on box 2 (rl2 interface), where the physical interface
has no IP address. It has 12 vlandevs which are each gateways to various
networks. I would like each of these vlandevs to show up as the next hop when
viewing rib from another connected router.
2) I entered interface vlan2 in ospf area 0.0.0.1, which is exchanging all 12
vlan routes with box3.
3) If I enter other vlan interfaces into area 0.0.0.1 on box2 (vlan3 { passive
} ), I suffer some ospf problems in area 0.0.0.0 on my gw (box1). Basically,
what happens is that I can reach the gw from box2 and box3 but not from
machines connected to vlan3 on box2...
4) On box3, all routes show up with next-hop of 10.1.0.1 (vlan2 on box2),
instead of the IP addresses of the respective vlan interfaces. I want the real
gateways to show up as next-hops.
box2
---
[root@box2 etc]# cat hostname.rl2
up descr VLAN_TRUNK group VLAN_TRUNK
[root@box2 etc]# cat hostname.vlan*
inet 10.1.56.1 255.255.248.0 NONE vlan 10 vlandev rl2
inet 10.1.64.1 255.255.248.0 NONE vlan 11 vlandev rl2
inet 10.1.72.1 255.255.252.0 NONE vlan 12 vlandev rl2
inet 10.1.76.1 255.255.252.0 NONE vlan 13 vlandev rl2
inet 10.1.80.1 255.255.248.0 NONE vlan 14 vlandev rl2
inet 10.1.88.1 255.255.248.0 NONE vlan 15 vlandev rl2
inet 10.1.0.1 255.255.248.0 NONE vlan 2 vlandev rl2
inet 10.1.8.1 255.255.252.0 NONE vlan 3 vlandev rl2
inet 10.1.12.1 255.255.252.0 NONE vlan 4 vlandev rl2
inet 10.1.16.1 255.255.252.0 NONE vlan 5 vlandev rl2
inet 10.1.32.1 255.255.252.0 NONE vlan 7 vlandev rl2
inet 10.1.48.1 255.255.248.0 NONE vlan 9 vlandev rl2
area 0.0.0.1 {
auth-type simple
auth-key $password
interface vlan2 { metric 10 }
}
[root@box2 ~]# ospfctl s n
ID Pri StateDeadTime Address Iface Uptime
10.1.0.12 1 FULL/DR 00:00:36 10.1.0.12 vlan2 03:13:12
10.0.0.11 FULL/BCKUP 00:00:31 10.0.0.1rl0 01:29:54
[root@box2 ~]# ospfctl s r
Destination Nexthop Path TypeType CostUptime
10.1.0.1210.1.0.12 Intra-Area Router10 03:13:20
10.1.0.0/21 10.1.0.1 Intra-Area Network 10 03:13:25
10.0.0.1 10.0.0.1 Intra-Area Router10 01:29:58
10.0.0.0/21 10.0.0.2 Intra-Area Network 10 01:30:08
0.0.0.0/010.0.0.1 Type 1 ext Network 110 01:29:58
10.2.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.3.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.4.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.5.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.6.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.7.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.8.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.9.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.10.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.11.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.12.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
10.13.1.0/24 10.1.0.12 Type 1 ext Network 110 03:13:20
box 3
--
[root@box3 ~]# ospfctl s r
Destination Nexthop Path TypeType CostUptime
10.0.0.1 10.1.0.1 Inter-Area Router20 01:45:09
10.0.0.2 10.1.0.1 Intra-Area Router10 03:28:33
10.0.0.0/21 10.1.0.1 Inter-Area Network 20 01:45:15
10.1.0.0/21 10.1.0.12 Intra-Area Network 10 03:28:38
0.0.0.0/010.1.0.1 Type 1 ext Network 120 01:45:09
10.1.8.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.12.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.16.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.32.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.48.0/21 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.56.0/21 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.64.0/21 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.72.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.76.0/22 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.80.0/21 10.1.0.1 Type 1 ext Network 110 03:28:33
10.1.88.0/21 10.1.0.1 Type 1 ext Network 110 03:28:33
10.100.103.0/24 10.1.0.1 Type 1 ext Network 110 03:28:33
192.168.1.0/24
Re: L2TP/IPSEC issue - Any generic pointers would be great
I'd start isakmpd in foreground mode(read verbose mode) and see what it prints
out, while iPad tries to connect to it.
On 15 jan 2013, at 20:35, Ted Wynnychenko wrote:
> Hello
>
> This may be off topic, since I don't think it's an openbsd issue, but
> (honestly) I have run out of ideas about where to go next.
>
> There aren't going to be many "specifics," since I don't know what details
> or outputs might be useful at this point.
>
>
>
> Here is my story (oh, this is just a home/personal situation).
>
>
>
> I have a openbsd 5.1 server as a firewall/ipsec server. This one also is
> able to accept L2TP (from my ipad) connections, and is running npppd.
>
> I have a second openbsd 5.1 server as a second firewall/ipsec server.
>
>
>
> When I set this up (over a year ago), everything worked great. The ipsec
> endpoints talk to each other, the tunnel comes up like magic, and I am able
> to backup data at a remote location without even thinking about.
>
> At the same time, I got npppd working, and was able to connect with my ipad
> when I wasn't at home to access "stuff" that I wanted to. I don't need to
> do this often.
>
>
>
> Well, 4-6 months ago, everything was good. The "static" IPSEC tunnel was
> working, and I could connect with the ipad.
>
>
>
> About 3 weeks ago I wanted to connect with the ipad and L2TP and no joy
> ("server not responding" that ipad says).
>
>
> And here is where I start getting lost.
>
>
>
> First, during this entire time, the "static" IPSEC tunnel has been rock
> stable (with the occasional dropout because my internet service provider
> drops my connection at one end or the other, but the "static" tunnel always
> comes back up when the connection is restored - maybe 5 or 10 minutes a day,
> usually at night).
>
>
>
> When trying to connect with the ipad, most (> 95%) of the time, the
> connection is unsuccessful. But, occasionally, the ipad connects. NO
> changes to configuration of the openbsd server, or changes to configuration
> of the ipad. It just happens. This may last for 3 minutes, or 5 minutes,
> or 7 minutes; but then it's gone.
>
>
> During these "connections," the tablet may or may not be able to access
> something on the internal/protected network. I have not seen a pattern so
> far, given the infrequent and limited connection opportunities.
>
>
>
> But, (to repeat) the "static" IPSEC tunnel is up the whole time.
>
>
>
> So, I tried this with a second ipad - same thing - most of the time it does
> not work; rarely, it works for a few minutes.
>
> I tried with an old laptop I have - using L2TP/IPSEC to establish a VPN; no
> success - I only tried with the laptop a dozen or so times, however.
>
> I tried from different locations, in different states, and different cities;
> same issue, most of the time no, rarely yes (Oh, by the way, almost all of
> these locations had been used in the past - prior to 6 months ago, and the
> ipad connected fine).
>
>
>
> Now, if I am at home, and try to connect to the now "local" IPSEC/L2TP
> server (from its internal interface) with the tablet, everything works fine,
> every time. Also, I can reliably access the network, and the network sees
> the traffic as coming from the L2TP server, and the associated VPN IP
> address.
>
>
>
> So, I used my meager knowledge to explore this issue - and here is where I
> REALLY get lost.
>
>
>
> Using tcpdump, I watch the L2TP/IPSEC server's external interface (so, I am
> looking at traffic before it hits PF or anything else - right?). Well,
> when the connections fail, there is NO traffic from the tablet getting to
> the external interface. At the same time, I can ssh into the server, and I
> can see that traffic using tcpdump fine (connecting from the same
> location/IP address that the ipad is trying to connect).
>
>
>
> On those rare occasions when the ipad is able to connect, I see packets
> coming in on the external interface for isakmpd, and then the established
> tunnel.
>
>
>
> During all of this, the "static" IPSEC tunnel is up and working.
>
>
>
> I have no idea where to go with this, or what to try.
>
> I feel like this is not related to the openbsd server, since when the tablet
> fails to connect, there is no traffic on the external interface.
>
> But, in that case, the failure is upstream (somewhere in the route between
> the tablet and the server). But, why would the other IPSEC tunnel be fine?
>
> If my ISP was filtering traffic, both shouldn't work, right?
>
> The variety of locations that I have tried to connect from and (mostly)
> failed, would seem to suggest the problem is near the "end" of the route
> back to the IPSEC/L2TP server, but that makes no sense to me either, since
> the "static" tunnel is rock solid.
>
>
>
> I am sorry for the long, rambling email. I wanted to thoroughly explain my
> issue, and since I don't really know what might have be important, I
> included the whole story.
>
>
>
>
L2TP/IPSEC issue - Any generic pointers would be great
Hello
This may be off topic, since I don't think it's an openbsd issue, but
(honestly) I have run out of ideas about where to go next.
There aren't going to be many "specifics," since I don't know what details
or outputs might be useful at this point.
Here is my story (oh, this is just a home/personal situation).
I have a openbsd 5.1 server as a firewall/ipsec server. This one also is
able to accept L2TP (from my ipad) connections, and is running npppd.
I have a second openbsd 5.1 server as a second firewall/ipsec server.
When I set this up (over a year ago), everything worked great. The ipsec
endpoints talk to each other, the tunnel comes up like magic, and I am able
to backup data at a remote location without even thinking about.
At the same time, I got npppd working, and was able to connect with my ipad
when I wasn't at home to access "stuff" that I wanted to. I don't need to
do this often.
Well, 4-6 months ago, everything was good. The "static" IPSEC tunnel was
working, and I could connect with the ipad.
About 3 weeks ago I wanted to connect with the ipad and L2TP and no joy
("server not responding" that ipad says).
And here is where I start getting lost.
First, during this entire time, the "static" IPSEC tunnel has been rock
stable (with the occasional dropout because my internet service provider
drops my connection at one end or the other, but the "static" tunnel always
comes back up when the connection is restored - maybe 5 or 10 minutes a day,
usually at night).
When trying to connect with the ipad, most (> 95%) of the time, the
connection is unsuccessful. But, occasionally, the ipad connects. NO
changes to configuration of the openbsd server, or changes to configuration
of the ipad. It just happens. This may last for 3 minutes, or 5 minutes,
or 7 minutes; but then it's gone.
During these "connections," the tablet may or may not be able to access
something on the internal/protected network. I have not seen a pattern so
far, given the infrequent and limited connection opportunities.
But, (to repeat) the "static" IPSEC tunnel is up the whole time.
So, I tried this with a second ipad - same thing - most of the time it does
not work; rarely, it works for a few minutes.
I tried with an old laptop I have - using L2TP/IPSEC to establish a VPN; no
success - I only tried with the laptop a dozen or so times, however.
I tried from different locations, in different states, and different cities;
same issue, most of the time no, rarely yes (Oh, by the way, almost all of
these locations had been used in the past - prior to 6 months ago, and the
ipad connected fine).
Now, if I am at home, and try to connect to the now "local" IPSEC/L2TP
server (from its internal interface) with the tablet, everything works fine,
every time. Also, I can reliably access the network, and the network sees
the traffic as coming from the L2TP server, and the associated VPN IP
address.
So, I used my meager knowledge to explore this issue - and here is where I
REALLY get lost.
Using tcpdump, I watch the L2TP/IPSEC server's external interface (so, I am
looking at traffic before it hits PF or anything else - right?). Well,
when the connections fail, there is NO traffic from the tablet getting to
the external interface. At the same time, I can ssh into the server, and I
can see that traffic using tcpdump fine (connecting from the same
location/IP address that the ipad is trying to connect).
On those rare occasions when the ipad is able to connect, I see packets
coming in on the external interface for isakmpd, and then the established
tunnel.
During all of this, the "static" IPSEC tunnel is up and working.
I have no idea where to go with this, or what to try.
I feel like this is not related to the openbsd server, since when the tablet
fails to connect, there is no traffic on the external interface.
But, in that case, the failure is upstream (somewhere in the route between
the tablet and the server). But, why would the other IPSEC tunnel be fine?
If my ISP was filtering traffic, both shouldn't work, right?
The variety of locations that I have tried to connect from and (mostly)
failed, would seem to suggest the problem is near the "end" of the route
back to the IPSEC/L2TP server, but that makes no sense to me either, since
the "static" tunnel is rock solid.
I am sorry for the long, rambling email. I wanted to thoroughly explain my
issue, and since I don't really know what might have be important, I
included the whole story.
If this is not an openbsd issue (which (frankly) I don't think it is), sorry
for the noise.
But, if anyone has a friendly (or, for that matter, and unfriendly)
suggestion of what I could try, please let me know.
Thanks.
Bye - ted
[demime 1.01d removed an attachment of type application/x-pkcs7-signature which
had a name of smime.p7s]
Re: new computer
On 2013-01-15 09:59, sven falempin wrote: On Fri, Jan 11, 2013 at 9:40 AM, john slee wrote: On 10 January 2013 22:21, Matt Morrow wrote: > You do realize the typical life of a battery is about a year? Poppycock. My FondletopPro battery still gives damn close to the performance it gave new in early 2011. The battery in my Fondleslab 3GS is near 4 years now and hasn't degraded that much either. Same again for my Dell Latitude corporate drone unit. If so many folks here are recommending Thinkpads, it's probably because (a) they are (or at least used to be) very well engineered laptops, and (b) shit works, yo. John laptop battery , what a joke . +1, Laptop batteries area planned to have a 1-2 year life, and some times you get less some times you get more, I have one Thinkpad that the battery lasted about 6 months and wont hold a charge, I have another that is 5 years old. asus: one of the ultra low cost pieces -may- break, the other will rock solid. For sure Asus is kind of a grab bag, but its generally a good bag. and btw, stop smoking, it is bad for your computer. +1 I usually like to ask peoples budgets before i give them recommendations but its almost always Asus or Thinkpad. -- Jason Barbier
Re: new computer
On Fri, Jan 11, 2013 at 9:40 AM, john slee wrote: > On 10 January 2013 22:21, Matt Morrow wrote: > > > You do realize the typical life of a battery is about a year? > > > Poppycock. > > My FondletopPro battery still gives damn close to the performance > it gave new in early 2011. The battery in my Fondleslab 3GS is > near 4 years now and hasn't degraded that much either. Same > again for my Dell Latitude corporate drone unit. > > If so many folks here are recommending Thinkpads, it's probably > because (a) they are (or at least used to be) very well engineered > laptops, and (b) shit works, yo. > > John > > laptop battery , what a joke . asus: one of the ultra low cost pieces -may- break, the other will rock solid. and btw, stop smoking, it is bad for your computer. -- - () ascii ribbon campaign - against html e-mail /\
Re: Routing confusion?
Turns out the problem had nothing to do with OpenBSD. For some reason one of the DSM routers (ZyXEL P-2601HN-F1) needed an explicit static return route, while the other, (FRITZ!Box Fon WLAN 7360) didn't. Everything works fine after adding the return route. Many thanks to everybody who responded! Julf On 14/01/13 18:36, Johan Helsingius wrote: > My firewall box has 3 net interfaces: > > > em0 (internal network): > inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 > em1 (internet): > inet 172.24.40.3 netmask 0xfc00 broadcast 172.24.43.255 > em2 (wifi sandbox): > inet 172.24.42.223 netmask 0xffc0 broadcast 172.24.42.255 > > Attached to em1 I have 2 ADSL modems, 172.24.40.1 and 172.24.40.2 > > Default route (set through /etc/mygate) is 172.24.40.1 > > The firewall itself ca reach both ADSL modems, but machines on > the internal network can only reach 172.24.40.1. Here are > traceroutes from a host inside the em0 network: > > traceroute to 172.24.40.1 (172.24.40.1), 30 hops max, 60 byte packets > 1 172.24.42.254 (172.24.42.254) 0.598 ms 0.685 ms 0.787 ms > 2 172.24.40.1 (172.24.40.1) 1.568 ms 1.560 ms 1.719 ms > > traceroute to 172.24.40.2 (172.24.40.2), 30 hops max, 60 byte packets > 1 172.24.42.254 (172.24.42.254) 1.251 ms 1.243 ms 1.235 ms > 2 * * * > > This is with pf disabled. > > As the packets do reach the firewall on em0, shouldn't they be > forwarded to em1? (yes, net.inet.ip.forwarding=1) > > Any advice/ideas/guidance appreciated... > > Julf
Re: PF: route-to round-robin using single interface?
Just confirming that after fixing non-OpenBSD-related
issues, round-robin works just fine even with only one
interface.
Julf
On 14/01/13 17:53, Johan Helsingius wrote:
> Hi!
>
> I have a small network, connected by 2 ADSL connections, and
> want to load-share the connections. All examples of route-to
> round-robin that I have seen have used 2 separate interfaces,
> but as both my ADSL modems are on the same "no-mans-land"
> network, I have been (so far unsuccessfully) trying to do
> something like this:
>
> pass in on $int_if from $int_net \
> route-to { ($ext_if $isp1_gw), ($ext_if $isp2_gw) } \
> round-robin sticky-address
>
> Is that supposed to work, or does route-to round-robin only
> work with 2 separate interfaces?
>
> Appreciate any input...
>
> Julf
Re: CARP compatibility between 5.1 and 5.2
Hi ! There is no problem as i Know and use Loic Blot Le 15 janv. 2013 à 12:50, "R0me0 ***" a écrit : > Hello misc, > > I've a OpenBSD 5.1 in production and I will put another OpenBSD 5.2 and > then configure CARP. > will I have some compatibility issue ? > > Thanks in advanced
Re: Routing confusion?
Peter, > :em0 (internal network): > :inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 > :em2 (wifi sandbox): > :inet 172.24.42.223 netmask 0xffc0 broadcast 172.24.42.255 > : > > You can't do that. What specific reason is there that that won't work? Isn't it just a minor variation of what is already going on here: em0 (internal network): inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 em1 (internet): inet 172.24.40.3 netmask 0xfc00 broadcast 172.24.43.255 where the internal network is a subnet of the external network? Isn't the routing based on the more specific netmask? Julf
Re: Routing confusion?
Aaron, > Another note, it would be prudent to put your ADSL modems onto each of > their own networks, or better yet (and if you can), run them in > bridge/modem mode and use pppoe(4) to fire up the connection. That > way the firewall is on the outside of the network. I did that for a long time, and it is a maintenance hassle when switching ISP's, or when the ISP changes something. I prefer to allow the ADSL modems/routers take care of NAT and other nitty-gritty related to the specific network they connect to, and use the firewall as a pure firewall. Julf
CARP compatibility between 5.1 and 5.2
Hello misc, I've a OpenBSD 5.1 in production and I will put another OpenBSD 5.2 and then configure CARP. will I have some compatibility issue ? Thanks in advanced
Re: Routing confusion?
On Tue, Jan 15, 2013 at 4:53 AM, Peter Hessler wrote: > On 2013 Jan 14 (Mon) at 18:36:05 +0100 (+0100), Johan Helsingius wrote: > :My firewall box has 3 net interfaces: > : > : > :em0 (internal network): > :inet 172.24.42.254 netmask 0xff00 broadcast 172.24.42.255 > :em2 (wifi sandbox): > :inet 172.24.42.223 netmask 0xffc0 broadcast 172.24.42.255 > : > > You can't do that. Make these seperate networks, or bridge em0 and em2 > together (but at that point, simply plug wifi into the internal network > switch). > > > -- > If a listener nods his head when you're explaining your program, wake > him up. > Another note, it would be prudent to put your ADSL modems onto each of their own networks, or better yet (and if you can), run them in bridge/modem mode and use pppoe(4) to fire up the connection. That way the firewall is on the outside of the network. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: named error from /var/named/etc/root.hint
On 2013-01-15, Jamie Paul Griffin wrote: > * Stuart Henderson [2013-01-14 10:54:30 +]: > >> On 2013-01-14, Jamie Paul Griffin wrote: >> > Hi >> > >> > I recently upgraded my system to the Dec 21 snapshot, will be updating >> > again to the Jan 09 snapshot; but, I noticed an error message in >> > /var/log/messages yesterday when I rebooted my machine: >> > >> > >> > Jan 13 21:16:43 kontrol named[23666]: checkhints: d.root-servers.net/A >> > (199.7.91.13) missing from hints >> > Jan 13 21:16:43 kontrol named[23666]: checkhints: d.root-servers.net/A >> > (128.8.10.90) extra record in hints >> > >> > I managed to fix it by downloading a new file from >> > ftp://ftp.internic.net/domain/named.cache and copying it to >> > /var/named/etc/root.hints. >> > >> > I Just thought I would post that in case anyone else has/had the same >> > issue. >> > >> > Cheers, Jamie >> > >> > >> >> This would get updated when you run sysmerge against newer sources >> or a newer etc52.tgz. > > I did run sysmerge(8) after the upgrade as documented. It must have been > something I did wrong then. Sorry for that. Dec 21 would have been too early for that; d.root didn't change address until after then. So you are fixed anyway by downloading from internic, and other people updating and running sysmerge now will also be fixed.
Re: I need a little more Enlightenment
On Tue, Jan 15, 2013 at 04:35:24PM +1100, Rod Whitworth wrote: > E installs without whining. > > I changed xinitrc to remove the icewm setting and added:- > exec enlightenment_start > > startx gives a very dark screen and a mouse cursor pops up in the > centre. Then the screen has a short flash of white all over before the > dark screen comes back without the mouse cursor. Hmmm... no idea what the problem could be. Sounds like the X server is crashing. Please show /var/log/Xorg.0.log, too. > dmesg follows: The dmesg you quoted is from 5.2. Please show the -current dmesg from the USB stick install which actually has the problem. I have another unrelated question about the machine: > "Realtek RTS5209 Card Reader" rev 0x01 at pci3 dev 0 function 0 not > configured > sdhc0 at pci3 dev 0 function 1 "Realtek RTS5209 Card Reader" rev 0x01: > apic 2 int 19 > sdmmc0 at sdhc0 Does the card reader work in 5.2? Does it work in -current?
