Re: Evernote Alternative?
Just a little addendum to your final post: I use OpenBSD as my desktop environment (also MAC OS and Linux) and I was looking for years for an outline application which I can use on every OS. Finally I switched from open to (paid) closed source *sigh* but now most of my problems were solved. I use notecasepro, an I think I'm the only user who uses it on OpenBSD, because I have to ask for a version running on an actual OpenBSD release. And no, this is not an advertisement, but my personal result after evaluating a lot of similar software which I can use on Linux, FreeBSD, MacOS but not on OpenBSD. Regards Andre Am 29.06.19 um 22:56 schrieb Chris Humphries: Final post. smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello Philipp, hello @misc I thought the problems were gone, but often deleting an unmamed phase 1 SA didn't work with the "cookie method" at least with 6.3/amd64. My way: 1.) # sh -c "echo S > /var/run/isakmpd.fifo" # less /var/run/isakmpd.result --> identify the dead phase 1 SA SA name: (Phase 1/Responder) src: dst: Lifetime: 28800 seconds Flags 0x icookie 7e0aab1278867246 rcookie f26398203e60007f 2.) try to delete the unnamed SA with your method: # sh -c "echo 'd 7e0aab1278867246f26398203e60007f -' \ > /var/run/isakmpd.fifo" results mostly in: ui_delete: command "d 7e0aab1278867246f26398203e60007f -" found no SA 3.) collateral problem: I'm not able to accept a new connection by the remote peer (with a new cookie) because isakmpd logs: transport_send_messages: giving up on exchange peer-, no response from peer . With tcpdump I can see that isakmpd refuses to answer peer requests 'till lifetime end or the crippled phase 1 is totally dropped... Resarting isakmpd is not advised 'cause of a lot of other active vpn sessions. The question: isakmpd bug or may brain incapabillities? Best regards Andre Am 15.05.18 um 05:15 schrieb Philipp Buehler: Hello Andre, Am 14.05.2018 13:38 schrieb Andre Ruppert: I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 Apparently I wrote that article, and I feel your pain :-) 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? The problem here is you only have an 'unnamed' SA, indeed; but you have cookies.. What you can do - found that a bit later after the undeadly article: echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo which is "d $icookie$rcookie -" (no space between the cookie values). If I am changing a peer configuration, I also block 500/udp for the time being to avoid these 'Responder' SAs altogether. Think along pf.conf:pass in proto udp from to $myself port 500 pfctl -T delete -t vpn_peers $thatpeer pfctl -k $thatpeer ipsecctl -d -f $thatpeer.conf vi $thatpeer.conf ipsecctl -f $thatpeer.conf pfctl -T add -t vpn_peers $thatpeer HTH, smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello Philipp, sorry for the late answer Thanks for the hint with the cookies. Works in my environment I'm much happier now ;-) Best regards Andre Am 15.05.18 um 05:15 schrieb Philipp Buehler: Hello Andre, Am 14.05.2018 13:38 schrieb Andre Ruppert: I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 Apparently I wrote that article, and I feel your pain :-) 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? The problem here is you only have an 'unnamed' SA, indeed; but you have cookies.. What you can do - found that a bit later after the undeadly article: echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo which is "d $icookie$rcookie -" (no space between the cookie values). If I am changing a peer configuration, I also block 500/udp for the time being to avoid these 'Responder' SAs altogether. Think along pf.conf:pass in proto udp from to $myself port 500 pfctl -T delete -t vpn_peers $thatpeer pfctl -k $thatpeer ipsecctl -d -f $thatpeer.conf vi $thatpeer.conf ipsecctl -f $thatpeer.conf pfctl -T add -t vpn_peers $thatpeer HTH, smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Remark below... Am 14.05.18 um 13:38 schrieb Andre Ruppert: Hello @misc, I use a CARPed pair of 6.2 gateways as vpn access nodes, running "plain" ISAKMPD/ipsec. The peering vpn gateways have different brandings from OpenBSD, linux, cisco to watchguard appliances etc... Interoperability works most like a charm and is a no-brainer in most cases. I have only access to the OpenBSD peering gateways, but most other brands belong to partners / customers. Sometimes I first have problems with some of these peering boxes and only partial tunnels came up (only phase 1 or - more bad - phase 1 only partial). Then I check the logs and - if I got wrong credentials or parameters from the peering partner - I change the configs on my side. It needs mostly much less time than to discuss with the technicians from the peering partners - their problems have to te solved by them by clicking somewhere in a webinterface *sigh*. Ok, back to _my_ problem: If a ipsec tunnel is running with phase 1 and 2, I can stop it with "ipsecctl -d -f ". Works. If the ipsec tunnel is only partial working, I can delete it by using the fifo mechanism. Sometimes. ( I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 ) But I have always problems if only a part of phase 1 came up. 1.) sh -c "echo S > /var/run/isakmpd.fifo" 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? Question to the community: how is it possible to reliable stop partial tunnels without restarting isakmpd/ipsec (e.g. disturbing all other running tunnels)? I'm clueless Best regards Andre ...and sh -c "echo 't main ' > /var/run/isakmpd.fifo" doesn't work either ... /var/log/daemon reports "...ui_teardown: teardown connection "", phase 1 but that doesn't do anything. Man isakmpd reads for fifo using: "t [phase] name" Tear down the named connection, if active. For name, the tag specified in isakmpd.conf(5) or the IP address of the remote host can be used. Hm. Again clueless... Best regards Andre smime.p7s Description: S/MIME Cryptographic Signature
OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello @misc, I use a CARPed pair of 6.2 gateways as vpn access nodes, running "plain" ISAKMPD/ipsec. The peering vpn gateways have different brandings from OpenBSD, linux, cisco to watchguard appliances etc... Interoperability works most like a charm and is a no-brainer in most cases. I have only access to the OpenBSD peering gateways, but most other brands belong to partners / customers. Sometimes I first have problems with some of these peering boxes and only partial tunnels came up (only phase 1 or - more bad - phase 1 only partial). Then I check the logs and - if I got wrong credentials or parameters from the peering partner - I change the configs on my side. It needs mostly much less time than to discuss with the technicians from the peering partners - their problems have to te solved by them by clicking somewhere in a webinterface *sigh*. Ok, back to _my_ problem: If a ipsec tunnel is running with phase 1 and 2, I can stop it with "ipsecctl -d -f ". Works. If the ipsec tunnel is only partial working, I can delete it by using the fifo mechanism. Sometimes. ( I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 ) But I have always problems if only a part of phase 1 came up. 1.) sh -c "echo S > /var/run/isakmpd.fifo" 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? Question to the community: how is it possible to reliable stop partial tunnels without restarting isakmpd/ipsec (e.g. disturbing all other running tunnels)? I'm clueless Best regards Andre
relayd as websocket proxy?
Hello @misc,
is it possible to configure relayd to act as a websocket proxy with
v6.2/v6.3?
I set up relayd as ssl accelerator:
excerpt from relayd.conf:
http protocol "httpfilter2" {
tcp { nodelay, sack, socket buffer 65536, backlog 100 }
return error
match request header set "Connection" value "close"
match header set "Keep-Alive" value "$TIMEOUT"
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" value \
"$SERVER_ADDR:$SERVER_PORT"
tls { tlsv1, ciphers "HIGH:!ADH:!NULL:!RC4:-ECDH:ECDHE" }
}
...
relay webrtc_wsc {
listen on $webrtc_wsc_relayd_addr \
port $webrtc_wsc_relayd_port tls
protocol "httpfilter2"
transparent forward to port $webrtc_wsc_web_port \
mode loadbalance http “/” code 200
}
...
valid .key and .crt-files are placed in /etc/ssl/private and /etc/ssl.
First: "standard" SSL acceleration works fine without problems.
Second: websocket connections don't :-(
As far I can see websocket upgrade messages (decoded in wireshark as
"HTTP/1.1 101 Switching Protocols" packets) from the internal server are
replaced by relayd with packets with the RST-flag set directed to the
WAN client and the connection is closed.
My head-scratching question:
is this possible at all with relayd?
Or do I have to switch to nginx?
Regards
Andre Ruppert
smime.p7s
Description: S/MIME Cryptographic Signature
Re: IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC
Fri, 16 Mar 2018 13:25:49 +0100 Janne Johansson : > 2018-03-16 12:26 GMT+01:00 Andre Ruppert : > > > Hello @misc, > > > > after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via > > 6.1 to 6.2 (amd64) I noticed some trouble with my VPN connections. > > > > Almost always when you get "expected 3DES" it means "the confs are not > matching so obsd chose some default thing which includes 3DES > which is not what the other side is running". > > Things like mixing up "from NetA to NetB" and the other side not > having the exact opposite is a decent way to get that exact error. > > I don't know what part changed so that it is no longer matching for > you, but something makes the negotiations not think > the remote proposal is what it expects, so it goes into some default > mode from which it will never make a connection. > I agree with you in principle, but the question is: why drop these connections (with untouched configurations) sporadically with 6.2 and _not_ with 6.0? Some of these connections drop several times in 24h. No problems at all with 6.0. And it's always the same behavior: first drops the esp tunnel and the esp flows remain active. And its not possible to stop them with 'ipsecctl -d -f ' Is it only possible to stop zombie-type flows with fifo commands? Best regards Andre
IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC
Hello @misc, after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via 6.1 to 6.2 (amd64) I noticed some trouble with my VPN connections. Scenario: - a CARPed OpenBSD VPN gateway with sasyncd (master and backup) - a bunch of customer VPN client gateways (several brands -> Sophos, Fortigate, Cisco , ... ). - ISAKMPD/ipsec (no iked yet) - no syntax errors in ipsec.conf files (checked) - with release 6.0 no problems at all. - with 6.2 sometimes several of the connections drop nearly at the same time and I have do restart them manually. Configuration: ipsec.conf includes - configuration is pretty simple - one include-file for every connection: # -- LOCAL_PEER = "IP_of_my_gateway" LOCAL_NET = "my_network/mask bits" REMOTE_NET_XY = "foreign_network_YX/mask bits" REMOTE_PEER_XY = "IP_of_remote_gateway" ike esp from $LOCAL_NET to $REMOTE_NET_XY \ peer $REMOTE_PEER_XY \ main auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 3600 \ quick auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 1200 \ srcid $LOCAL_PEER psk "SomethingTotalSecretAsPSKsCanBe" Single VPNs are startet by "ipsecctl -f /etc/ipsec/ipsec.include.xy" and deleted by "ipsecctl -d -f /etc/ipsec/ipsec.include.xy) (Deleting connections is a special matter and doesn't work well, but that is not the point here) The problem so far: prior to the connection drops I see isakmpd error messages: isakmpd[35939]: dropped message from "REMOTE_PEER_XY" port 500 due to notification type NO_PROPOSAL_CHOSEN isakmpd[35939]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC isakmpd[35939]: message_negotiate_sa: no compatible proposal found My question: why (and where) do I expect 3DES_CBC encrytion ? And sometimes also other additional error messages appear in the Log. Example: ... ipsec_get_id: section to-10.10.244.0/25 has no "ID-type" tag Mar 16 08:06:11 redacc01-a isakmpd[35939]: connection_init: could not record connection "from-172.16.0.0/16-to-10.10.244.0/25" ... I'm clueless... There are no infos in the upgrade guides (6.0 to 6.1 and 6.1 to 6.2) concerning isakmpd/ipsec changes Sysctl lists: net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.ipsec-comp-alg=deflate Any hints? Best regards Andre Ruppert smime.p7s Description: S/MIME Cryptographic Signature
VLAN configuration problem on 6.1 ("no route to host" on other than own IP)
Hello @misc,
perhaps I'm stupid, but I don't see my fault in a vlan network
configuration:
I got a OpenBSD 6.1 gateway box, connected to several switches.
On em0 I habe to serve two networks:
172.16.210.0 (direct em0 - no vlan)
172.16.211.0 (VLAN 211 tagged on em0)
On of my connections (em0) has a simple configuration on standard VLAN 1
(untagged):
# ifconfig em0
em0: flags=8b43
mtu 1500
lladdr a0:36:9f:36:49:e6
description: sbc-ect-lan-ext
index 1 priority 0 llprio 3
media: Ethernet autoselect (1000baseT full-duplex,master)
status: active
inet 172.16.210.3 netmask 0xff00 broadcast 172.16.210.255
# cat /etc/hostname.em0
inet 172.16.210.3 255.255.255.0 172.16.210.255 description "sbc-ect-lan-ext"
--
This interface also is "CARPed":
# ifconfig carp0
carp0: flags=8843 mtu 1500
lladdr 00:00:5e:00:01:01
index 8 priority 15 llprio 3
carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
groups: carp
status: backup
inet 172.16.210.1 netmask 0xff00 broadcast 172.16.210.255
# cat /etc/hostname.carp0
inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 carpdev em0 pass
advskew 100
(this gateway is the CARP slave (backup) of a pair of redundant gateways)
---
Next: I want to have a VLAN on this interface em0:
(the connected switch has a trunk configured this VLAN 210 (untagged)
and VLAN 211 (tagged) - but I don't know if this information makes sense
here)
# ifconfig vlan211
vlan211: flags=8843 mtu 1500
lladdr a0:36:9f:36:49:e6
index 15 priority 0 llprio 3
vlan: 211 parent interface: em0
vnetid: 211
parent: em0
groups: vlan
status: active
inet 172.16.211.3 netmask 0xff00 broadcast 172.16.211.255
# cat /etc/hostname.vlan211
inet 172.16.211.3 255.255.255.0 172.16.211.255 vlandev em0
--
corresponding routing table (excerpt):
# netstat -nr
Routing tables
Internet:
DestinationGatewayFlags Refs Use Mtu Prio
Iface
default172.16.0.15UGS1 191 - 8
...
...
172.16.210/24 172.16.210.3 UCn1 1094 - 4 em0
172.16.210/24 172.16.210.1 Cn 00 -19
carp0
172.16.210.1 00:00:5e:00:01:01 UHLl 0 153 - 1
carp0
172.16.210.3 a0:36:9f:36:49:e6 UHLl 0 275 - 1 em0
172.16.210.10 00:08:25:22:50:e0 UHLc 0 158 - 3 em0
172.16.210.255 172.16.210.3 UHPb 00 - 1 em0
172.16.210.255 172.16.210.1 HPb00 - 1
carp0
172.16.211/24 172.16.211.3 UCn0 1215 - 4
vlan211
172.16.211.3 a0:36:9f:36:49:e6 UHLl 00 - 1
vlan211
172.16.211.255 172.16.211.3 UHb00 - 1
vlan211
-
My problem:
I am only able to ping myself (VLAN 211) - end I _don't_ think it's a
switch problem - because I get an "no route to host" error
# ping 172.16.211.3 # (my IP)
PING 172.16.211.3 (172.16.211.3): 56 data bytes
64 bytes from 172.16.211.3: icmp_seq=0 ttl=255 time=0.153 ms
64 bytes from 172.16.211.3: icmp_seq=1 ttl=255 time=0.080 ms
...
...stupid but working as expected...
# ping 172.16.211.2 # some other IP, same network
PING 172.16.211.2 (172.16.211.2): 56 data bytes
ping: sendmsg: No route to host
ping: wrote 172.16.211.2 64 chars, ret=-1
ping: sendmsg: No route to host
ping: wrote 172.16.211.2 64 chars, ret=-1
ping: sendmsg: No route to host
...
The routing table then has added one new entry:
172.16.211/24 172.16.211.3 UCn1 1743 - 4
vlan211
172.16.211.2 link#15UHLc 0 1684 - 3
vlan211 !
172.16.211.3 a0:36:9f:36:49:e6 UHLl 0 18 - 1
vlan211
172.16.211.255 172.16.211.3 UHb00 - 1
vlan211
I'm clueless and don't know how to investigate further...
In my pf.conf I tried to "temporarly annihilate" the rules on the em0
interface ("set skip on em0"), but that didn't help
Any hints?
head-scratching regards
Andre Ruppert
smime.p7s
Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.1: relayd does not start more than 3 processes
Hm, I got a relayd-problem with a similar config. 100% CPU load nearly all 10 days with 5.9, same behavior all 3-4 weeks with 6.0. Wrong-ordered relayd.conf too. looks like this when running in trouble: _relayd 33851 100.0 0.1 2004 4496 ?? Rp15Apr17 3363:59.52 relayd: relay (relayd) _relayd 94800 0.0 0.1 2208 4720 ?? Sp15Apr171:01.44 relayd: relay (relayd) root 92841 0.0 0.1 1724 3996 ?? Is15Apr170:01.70 /usr/sbin/relayd -v _relayd 65955 0.0 0.1 1328 3436 ?? Sp15Apr170:11.41 relayd: pfe (relayd) _relayd 40687 0.0 0.1 1240 3264 ?? Sp15Apr170:28.04 relayd: hce (relayd) _relayd 75933 0.0 0.1 1220 3404 ?? Ip15Apr170:37.44 relayd: ca (relayd) _relayd 82476 0.0 0.1 1216 3304 ?? Ip15Apr170:35.52 relayd: ca (relayd) I just re-ordered my config. No let's see if it still comes to trouble in the next weeks... ;-) Andre Am 05.05.17 um 16:05 schrieb Maxim Bourmistrov: Hm, I tried this out - re-ordering the layout of the config. You are, indeed, correct here. Strange that this runs on 6.0. Case closed. Sorry for the noise. Br smime.p7s Description: S/MIME Cryptographic Signature
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
Hi,
Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II).
No kernel panics at all, and these systems are working in a live
environment...
Regards
Andre
Am 02.05.17 um 15:03 schrieb Mathieu BLANC:
On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
It also kernel panics with just this pf rules :
# cat pf_minimal.conf
set limit { states 10 }
set skip on lo
anchor "relayd/*"
pass
I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Please: Is there ANY chance that Linux binaries might run again???
Softmaker doesn't support any of the BSDs - they've done it years ago for FreeBSD but the customer's interest was too little. Am 07.03.17 um 23:52 schrieb Damian McGuckin: > On Tue, 7 Mar 2017, Stefan Wollny wrote: > >> Yes - I will (again) contact SoftMaker trying to persuade them to >> provide an OpenBSD-version of their office suite. But they seem to have >> none with some decent Unix/OpenBSD-knowledge, just Linux. Sigh... > > I would buy SoftMaker on OpenBSD. Andre Ruppert [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: OpenBSD 6.0 amd64 Release --> pkg_add returns error when running as Virtualbox guest
Hello again, Date: 17.11.16 time: 18:32 - Christer Solskogen wrote: > Try use bridge mode instead of NAT. I had the exact same problem on > Windows 10 as a host. > > -- > chs > ...that hit the point. Tested on Mac OS and Win10 as host - same solution. Thank You! My former tested bridged-setup failed due to stupidity of myself... But what I yet not know: what's the reason for this kind of error ... but that's maybe a academical question ;-) regards Andre
OpenBSD 6.0 amd64 Release --> pkg_add returns error when running as Virtualbox guest
Hello to the list, this morning I stumbled about a "pkg_add" problem when running OpenBSD 6.0 amd64 Release on an actual Virtualbox release. Doesn't matter which host platform (I tried Mac OS Sierra and Windows 10 and 7). Virtualbox settings: 5GB hardisk 512 MB RAM tested two network card settings: virtio-net and Intel 1000 Pro desktop tested NATed and bridged settings. Version: OpenBSD 6.0 (GENERIC) #2148: Tue Jul 26 12:55:20 MDT 2016 for example: (used a local mirror) # pkg_add wget quirks-2.241 signed on 2016-07-26T16:56:10Z wget-1.18:libunistring-0.9.6p0: ok Fatal error: Ustar [http://ftp.halifax.rwth-aachen.de/openbsd/6.0/packages/amd64/libidn-1.32p1.t gz][share/emacs/site-lisp/idna.el]: Premature end of archive Adjusting sha for /usr/local/share/emacs/site-lisp/pkg.VkQ6RBfrzy from DF8Nwh8xhTWpgYsivuBL7K8CMpbPKojbQJsyD0Paplk= to 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= Fatal error: Installation of libidn-1.32p1 failed, partial installation recorded as partial-libidn-1.32p1 at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 817. -- doesn't depend on mirror -- doesn't depend on guest RAM settings -- doesn't depend on guest network card settings -- doesn't depend on acceleration settings in Virtualbox (well, I think so...) ...and a little bit strange: _sometimes_ pkg_add works with small packages: example 2a (same as ex 1): # pkg_add ipcalc quirks-2.241 signed on 2016-07-26T16:56:10Z Fatal error: Ustar [http://ftp.halifax.rwth-aachen.de/openbsd/6.0/packages/amd64/ipcalc-1.4p0.tg z][bin/ipcalc]: Premature end of archive Adjusting sha for /usr/local/bin/pkg.F5nNSjqcJf from Htiq8Hrei0yMn/IWm+Y9dXTq3pZeZyBrbbv98+o9eoA= to 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= Fatal error: Installation of ipcalc-1.4p0 failed, partial installation recorded as partial-ipcalc-1.4p0 at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 817. example 2b: # rm -R /var/db/pk/partial-* # pkg_add ipcalc quirks-2.241 signed on 2016-07-26T16:56:10Z ipcalc-1.4p0: ok Building packages from ports works fine (apparently) Any hints to look further? Anyone who had similar problems? Every hint is welcome, I'm clueless... ;-) best regards Andre Ruppert [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: carp/pfsync-problem: carp states stuck in "INIT" on boot on both machines but work correctly if called manually via /etc/netstart
...I don't believe it... I ssh'd all the time to the gateways and never had a look to the bootmessages 2x "ifconfig invalid argument" was the hint at boot. The fault (syntax typo?) was included in hostname.carp[0,1] - "\" for a 2-liner didn't work... despite the usage of blanks only. Crunched it to a 1-liner and all worked... Seems that the parsing is different at booting? Andre Am 02.10.15 um 10:37 schrieb Andre Ruppert: Hello @list, perhaps I'm stupid but I've got a problem with two CARPed gateways running 5.7-amd64 stable. Hardware: two supermicro-board machines with four network interfaces each (em0 .. em3). Networks: LAN A : 172.16.210/24 via em0 LAN B : 172.16.0/24 via em1 direct connect for pfsync: 1.1.1.0/30 via em3 Gateway A setup --- (master) --- hostname.em0: "inet 172.16.210.2 255.255.255.0" hostname.em1: "inet 172.16.0.30 255.255.255.0" hostname.em3 "inet 1.1.1.1 255.255.255.252 1.1.1.3" hostname.carp0 "inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 \ carpdev em0 pass gwvoip01carppass advskew 0" hostname.carp1 "inet 172.16.0.29 255.255.255.0 172.16.0.255 vhid 2 \ carpdev em1 pass gwvoip01carppass advskew 0" hostname.pfsync0 "up syncdev em3 syncpeer 1.1.1.2" sysctl net.inet.carp -> net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=7 #debugging Gateway B setup --- (backup) --- hostname.em0: "inet 172.16.210.3 255.255.255.0" hostname.em1: "inet 172.16.0.31 255.255.255.0" hostname.em3 "inet 1.1.1.2 255.255.255.252 1.1.1.3" hostname.carp0 "inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 \ carpdev em0 pass gwvoip01carppass advskew 100" hostname.carp1 "inet 172.16.0.29 255.255.255.0 172.16.0.255 vhid 2 \ carpdev em1 pass gwvoip01carppass advskew 100" hostname.pfsync0 "up syncdev em3 syncpeer 1.1.1.1" sysctl net.inet.carp -> net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=2 problem description -- (remark: failover-switching works on both machines in both directions) If one of the machines reboots, the local carp-interfaces stuck in "INIT" state. Same behavior on both systems. The log (A) after reboot: carp: carp0 demoted group carp by -1 to 162 (carpdev) carp: carp1 demoted group carp by -1 to 161 (carpdev) carp: pfsync0 demoted group carp by -1 to 32 (pfsync bulk done) carp: pfsync0 demoted group pfsync by -1 to 32 (pfsync bulk done) carp: pfsync0 demoted group carp by -32 to 0 (pfsync init) carp: pfsync0 demoted group pfsync by -32 to 0 (pfsync init) If the carp-interfaces are subsequently restartet via netstart command, all works like a charm again... The log (A) after "sh /etc/netstart [carp0,carp1]": carp0: state transition: INIT -> BACKUP state transition: BACKUP -> MASTER state transition: INIT -> BACKUP state transition: BACKUP -> MASTER No PF-ruleset-problem! resulting question - what the heck is going on here? ;-) alternative: what did I forgot to configure? Thanks for reading... Andre Ruppert
carp/pfsync-problem: carp states stuck in "INIT" on boot on both machines but work correctly if called manually via /etc/netstart
Hello @list, perhaps I'm stupid but I've got a problem with two CARPed gateways running 5.7-amd64 stable. Hardware: two supermicro-board machines with four network interfaces each (em0 .. em3). Networks: LAN A : 172.16.210/24 via em0 LAN B : 172.16.0/24 via em1 direct connect for pfsync: 1.1.1.0/30 via em3 Gateway A setup --- (master) --- hostname.em0: "inet 172.16.210.2 255.255.255.0" hostname.em1: "inet 172.16.0.30 255.255.255.0" hostname.em3 "inet 1.1.1.1 255.255.255.252 1.1.1.3" hostname.carp0 "inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 \ carpdev em0 pass gwvoip01carppass advskew 0" hostname.carp1 "inet 172.16.0.29 255.255.255.0 172.16.0.255 vhid 2 \ carpdev em1 pass gwvoip01carppass advskew 0" hostname.pfsync0 "up syncdev em3 syncpeer 1.1.1.2" sysctl net.inet.carp -> net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=7 #debugging Gateway B setup --- (backup) --- hostname.em0: "inet 172.16.210.3 255.255.255.0" hostname.em1: "inet 172.16.0.31 255.255.255.0" hostname.em3 "inet 1.1.1.2 255.255.255.252 1.1.1.3" hostname.carp0 "inet 172.16.210.1 255.255.255.0 172.16.210.255 vhid 1 \ carpdev em0 pass gwvoip01carppass advskew 100" hostname.carp1 "inet 172.16.0.29 255.255.255.0 172.16.0.255 vhid 2 \ carpdev em1 pass gwvoip01carppass advskew 100" hostname.pfsync0 "up syncdev em3 syncpeer 1.1.1.1" sysctl net.inet.carp -> net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=2 problem description -- (remark: failover-switching works on both machines in both directions) If one of the machines reboots, the local carp-interfaces stuck in "INIT" state. Same behavior on both systems. The log (A) after reboot: carp: carp0 demoted group carp by -1 to 162 (carpdev) carp: carp1 demoted group carp by -1 to 161 (carpdev) carp: pfsync0 demoted group carp by -1 to 32 (pfsync bulk done) carp: pfsync0 demoted group pfsync by -1 to 32 (pfsync bulk done) carp: pfsync0 demoted group carp by -32 to 0 (pfsync init) carp: pfsync0 demoted group pfsync by -32 to 0 (pfsync init) If the carp-interfaces are subsequently restartet via netstart command, all works like a charm again... The log (A) after "sh /etc/netstart [carp0,carp1]": carp0: state transition: INIT -> BACKUP state transition: BACKUP -> MASTER state transition: INIT -> BACKUP state transition: BACKUP -> MASTER No PF-ruleset-problem! resulting question - what the heck is going on here? ;-) alternative: what did I forgot to configure? Thanks for reading... Andre Ruppert
Re: offtopic: political correctness
Any other problems? Am 08.05.15 um 16:30 schrieb Marko Cupać: Hi, I am reading 2nd edition of "Absolute OpenBSD 2nd Edition" and can't but notice paragraph "Confidentiality" on XXX page of Introduction: ---cut-here--- Confidentiality This means that secret data should remain secret. Your private infor- mation must not get into the public eye. That Eastern European kiddie porn syndicate should not get your credit card number. ---cut-here--- This sound quite nazi to me. Should Western European kiddie porn syndicate be able to get my credit card number, as opposed to Eastern European kiddie porn syndicate, which should not? Or does that mean that kiddie porn syndicate exists only in Eastern Europe, but not in - let's say - New Zealand or Canada? I guess this was intended to be a joke, but in my opinion it sucks. -- Andre Ruppert
Re: pf+voip
Tue, 27 May 2014 13:59:07 +0400
Швецов Михаил wrote:
> Does pf have specific rules for voip, may be example of working
> pf_rule with voip?
>
> Because for «standart rules» i have problems with voip.
>
> set skip on lo
>
> match out on pppoe0 from { em1:network } nat-to (pppoe0)
>
> block
>
> pass out
>
> pass in on { em1 }
>
> - after hanging up, the line near 3 minutes still busy (may be keep
> state set to no state in rules)
>
> - badly hear person on the phone (quiet)
>
VoIP in NAT environments isn't this simple.
You have two different protocols: SIP for signaling und RTP for media.
Media information between the endpoints is specified in SIP-SDP-packets
(session description protocol).
SDP-packets contain the original IPs of the VoIP-endpoints, and these
IPs won't be NATed!
Do you make use of an sip-proxy or an external STUN-server at least?
--
Andre Ruppert
Network Administrator
V5.0 -> ipsec --> lifetime dependencies between ipsec.conf (ipsecctl) and isakmpd.conf
Hello @misc, I'm lost in the documentation of isakmpd.conf and ipsec.conf :-( Situation: I have to set up several ipsec-connections on one system on my side (OBSD 5) to different sites with different VPN-hardware. All external sites offer only PSKs in configuration, no certificates. Problem: most of the sites use different key lifetimes (in phase 1/2), so I have do deal with a bunch of lifetime values. Question: is there any chance (perhaps in the future) to integrate lifetime parameters via ipsecctl --> ipsec.conf or will I be forced to keep on using isakmpd.conf? I don't need isakmpd.conf for other parameters ;-) best regards Andre Ruppert
Re: OpenBSD on Dell PowerEdge
Am Mon, 8 Aug 2011 11:37:43 +0200 schrieb Michael Lechtermann : [cut] > > Looking at the specs, a Dell R410 (or R610) would meet the > requirements regarding hot-swap HDDs (RAID 1) and redundant power > supply, but... > > Can anyone please confirm that OpenBSD is running on that hardware > and what raid controller would be a good choice? > > The boxes are also to have 6 network interfaces. Which additional > Quad NIC would be the best to take, Broadcom or Intel? > [cut] Never had problems with the Dell Rx10-class, but I don't use RAID. And I use Intel Pro dual NICs in most of my Dell Equipment. Again - no problems at all... Regards Andre Ruppert
Re: dell latitude d430 + port replicator -- is okay?
> On Mon, Feb 7, 2011 at 10:50 AM, Andre Ruppert > wrote: > > > No problems - except UMTS, but I don't need it... > > Can you provide the output of "usbdevs -dv"? You're welcome ;-) Controller /dev/usb0: addr 1: high speed, self powered, config 1, EHCI root hub(0x), Intel(0x8086), rev 1.00 uhub0 port 1 powered port 2 addr 2: high speed, self powered, config 1, product 0xa005(0xa005), Dell(0x413c), rev 50.18 uhub5 port 1 powered port 2 addr 3: full speed, power 100 mA, config 1, Novatel Wireless HSDPA Modem(0x8137), Novatel Wireless(0x413c), rev 0.00, iSerialNumber Novatel Wireless HSDPA Modem ugen0 port 3 addr 4: full speed, power 200 mA, config 1, product 0x7761(0x7761), vendor 0x0b97(0x0b97), rev 1.10 uhub6 port 1 powered port 2 addr 5: full speed, self powered, config 1, O2Micro CCID SC Reader(0x7762), O2(0x0b97), rev 1.10 ugen1 port 3 powered port 4 addr 6: full speed, self powered, config 1, Bluetooth(0x8103), Dell(0x413c), rev 35.38 ubt0 port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 addr 7: high speed, self powered, config 1, product 0x0058(0x0058), Dell(0x413c), rev 10.00 uhub7 port 1 powered port 2 addr 8: high speed, self powered, config 1, product 0x0058(0x0058), Dell(0x413c), rev 10.00 uhub8 port 1 powered port 2 addr 9: low speed, power 100 mA, config 1, USB Optical Mouse(0x4d22), Primax Electronics(0x0461), rev 2.00 uhidev0 port 3 powered port 4 powered port 3 addr 10: high speed, self powered, config 1, A04(0x9001), Dell USB Drive(0x413c), rev 2.00 umass0 port 4 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub1 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub2 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub3 port 1 powered port 2 powered Controller /dev/usb4: addr 1: full speed, self powered, config 1, UHCI root hub(0x), Intel(0x8086), rev 1.00 uhub4 port 1 powered port 2 powered > I think the umts minicard should work after my commit > (see: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/umsm.c) Thank you, I'll give it a try next weekend... Andre Ruppert
Re: dell latitude d430 + port replicator -- is okay?
rev 0x01: apic 2 int 20 (irq 9) uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: apic 2 int 21 (irq 10) uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: apic 2 int 22 (irq 5) uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: apic 2 int 23 (irq 3) ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: apic 2 int 20 (irq 9) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe1 pci4 at ppb3 bus 2 cbb0 at pci4 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb4: apic 2 int 19 (irq 255) "Ricoh 5C552 Firewire" rev 0x09 at pci4 dev 1 function 1 not configured sdhc0 at pci4 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x18: apic 2 int 18 (irq 3) sdmmc0 at sdhc0 xl0 at pci4 dev 8 function 0 "3Com 3c905B 100Base-TX" rev 0x30: apic 2 int 16 (irq 11), address 00:50:04:6a:ec:2e exphy0 at xl0 phy 24: 3Com internal media interface cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x0, lattimer 0x20 pcmcia0 at cardslot0 ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x01: PM disabled pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 pciide0: channel 1 ignored (disabled) ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: SMI iic0 at ichiic0 spdmem0 at iic0 addr 0x51: 256MB DDR2 SDRAM non-parity PC2-3200CL5 SO-DIMM usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci3: USB revision 1.0 uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 mtrr: Pentium Pro MTRR support sdmmc0: can't enable card uhub5 at uhub0 port 2 "Dell product 0xa005" rev 2.00/50.18 addr 2 ugen0 at uhub5 port 2 "Novatel Wireless Novatel Wireless HSDPA Modem" rev 1.10/0.00 addr 3 uhub6 at uhub5 port 3 "vendor 0x0b97 product 0x7761" rev 1.10/1.10 addr 4 ugen1 at uhub6 port 2 "O2 O2Micro CCID SC Reader" rev 1.10/1.10 addr 5 ubt0 at uhub5 port 4 "Dell Bluetooth" rev 2.00/35.38 addr 6 uhub7 at uhub0 port 8 "Dell product 0x0058" rev 2.00/10.00 addr 7 uhub8 at uhub7 port 2 "Dell product 0x0058" rev 2.00/10.00 addr 8 uhidev0 at uhub8 port 2 configuration 1 interface 0 "Primax Electronics USB Optical Mouse" rev 2.00/2.00 addr 9 uhidev0: iclass 3/1 ums0 at uhidev0: 3 buttons, Z dir wsmouse1 at ums0 mux 0 umass0 at uhub7 port 3 configuration 1 interface 0 "Dell USB Drive A04" rev 2.00/2.00 addr 10 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, initiator 0 cd0 at scsibus0 targ 1 lun 0: SCSI0 5/cdrom removable softraid0 at root root on cd0a swap on cd0b dump on cd0b ehci_idone: ex=0xd1b1ca00 is done! Andre Ruppert
Re: OpenBSD and ISDN TA
Sorry, no chance Regards Andre Ruppert
Re: mutiple pptp pass-through PF
A short "user's view" from a simple OBSD user: Pptp is a security risk, d'accord. But here in Germany, a lot of H.323-VoIP-systems (gates and clients) work with pptp tunneling to be independent from H.323-NAT on firewalls. The corresponding dual-homed VoIP-gateways accept pptp from their VoIP-Clients in different locations. Ipsec stacks are not supportet. So, at least H.323 VoIP technology would appreciate this diff :-) Greetings Andre Ruppert
Re: O'Reilly Net article: short comparison between Cisco PIX, Smoothwall
...and OpenBSD, of course... sorry, I forgot Andre
O'Reilly Net article: short comparison between Cisco PIX, Smoothwall
http://www.oreillynet.com/pub/a/sysadmin/2007/02/15/evaluating_firewalls.html ...have fun... greetings Andre Ruppert
Re: strange userland pppoe behavior after replacing a v3.4 gateway with v3.7
Am Mon, 22 Aug 2005 15:24:40 +0200 Ivo Dijkhuis <[EMAIL PROTECTED]> schrieben Sie: > Andre Ruppert wrote: > > Hello to the list... > > > > The problem: a long time running stable v3.4 OBSD VPN gateway > > running behind a (german) SDSL line was replaced with a gateway > > version 3.7(stable). > > > > Now I got ppp mtu problems and can't see why. > > Most config-files were just copied from v3.4, the ppp.conf file > > didn't change: > > > > # > > default: > > set log all -sync -physical -tcp/ip -DNS > > set redial 10 0 > > set reconnect 10 20 > > set timeout 0 > > set device "!/usr/sbin/pppoe - -i xl0" > > set speed sync > > disable acfcomp protocomp ipv6cp > > deny acfcomp > > set ifaddr 10.0.0.1/0 10.0.0.2/0 > > enable mssfixup > > accept lqr > > > > connect: > > set authname "kjfvkjfdkjdfgkj" > > set authkey "jfhkfhfjhfvjkhfk" > > set mtu max 1416 > > set mru max 1416 > > add! default HISADDR > > ## > > > > > > pppoe (v3.7) is still userland. > > Don't ask why mtu is 1416 - all traffic is sent through an l2tp > > tunnel too, so it's a "must". ;-) > > > > Both sides are running OBSD VPN gateways (ipsec/ISAKMPD). > > Remote gateway is always a v3.4 version. > > > > With v3.7 I got ppp log messages: > > tun0: Error: ip_Input: deflink: wrote 1452, got Message too long > > I don't use ppp, but I've seen similar MTU problems with IPsec > traffic. Using scrub on the enc in pf.conf did solve this problem. > > Maybe you can try something like : > > scrub in on tun0 all no-df max-mss 1416 > scrub out on tun0 all no-df max-mss 1416 > > > Regards, > > Ivo > Thanks f|r the hint, tried it yesterday - nope! ;-) Still the same error message... I will replace the v3.7-stable with a v3.6-stable and have a look. I'll post the results... Greetings Andre Ruppert
strange userland pppoe behavior after replacing a v3.4 gateway with v3.7
Hello to the list... The problem: a long time running stable v3.4 OBSD VPN gateway running behind a (german) SDSL line was replaced with a gateway version 3.7 (stable). Now I got ppp mtu problems and can't see why. Most config-files were just copied from v3.4, the ppp.conf file didn't change: # default: set log all -sync -physical -tcp/ip -DNS set redial 10 0 set reconnect 10 20 set timeout 0 set device "!/usr/sbin/pppoe - -i xl0" set speed sync disable acfcomp protocomp ipv6cp deny acfcomp set ifaddr 10.0.0.1/0 10.0.0.2/0 enable mssfixup accept lqr connect: set authname "kjfvkjfdkjdfgkj" set authkey "jfhkfhfjhfvjkhfk" set mtu max 1416 set mru max 1416 add! default HISADDR ## pppoe (v3.7) is still userland. Don't ask why mtu is 1416 - all traffic is sent through an l2tp tunnel too, so it's a "must". ;-) Both sides are running OBSD VPN gateways (ipsec/ISAKMPD). Remote gateway is always a v3.4 version. With v3.7 I got ppp log messages: tun0: Error: ip_Input: deflink: wrote 1452, got Message too long Nothing on the LAN-side changed. I looked in the archives and googled around - some similar questions, few answers, and all doesn't hit the problem. Changelog didn't help too. Or I am way too stupid Funny: when I reduce the mtu on the client machines (XP/2000) to 1416, the error messages disappear, but tcp-traffic doesn't work yet. I had to re-replace v3.7 with v3.4 again :-(( Any suggestions or hints? greetings Andre Ruppert
transparent http-proxy for incoming pptp connections - direction outbound ... ?
...sounds perhaps a little bit funny description: Gateway (3.6) with two nics: ext_if (WAN/a.b.c.d) and int_if (LAN/192.168.0.1/16). Gateway is: transparent http proxy (squid/tproxy on LAN-Int 192.168.0.1) IPsec gateway (net2net - 28 static vpn tunnel) pptp gateway (for dumb mobile clients) client adress pool: 10.1.1/24 ...and other The problem:forcing the _incoming_ pptp clients to use the transparent proxy for _outgoing_ http requests. squid/tproxy are bound to LAN-Int, because otherwise they aren't tunnel members and not reachable for the clients. If the pptp clients call the squid proxy directly via their browser settings, all works well. But transparent proxying doesn't work :-( NAT is enabled for pptp clients (direction outbound) - works. Redirecting for port 80 requests (direction: WAN) to the tproxy: not working. I have lines similar to this in pf.conf: rdr on tun0 proto tcp from 10.1.1/24 to any port 80 -> 192.168.0.1 port 8081 ...but tproxy ist never affected Nearly the same settings from internal LAN work very well too... Perhaps I made the mistake when using tun-whatsoever? All hints welcome ;-) Andre Ruppert
Re: 4port Realtek nic
On Thu, 16 Jun 2005 12:36:06 +0100 Andy Hayward <[EMAIL PROTECTED]> wrote: > On 6/16/05, Nick Holland <[EMAIL PROTECTED]> wrote: > > I have a couple similarly marketed, similarly described cards > > (although, with a cheap dc(4) chip), and while they are VERY useful, > > they are not four-port NICs. What it actually is is a single port > > NIC with a four port switch. I'm fairly sure this is the exact same > > thing. Evidence: the picture seems to show two moderately small > > chips, most quad-port NICs have five chips -- four NICs and a > > PCI-PCI bridge. COULD it be a PCI-PCI bridge and a quad-port NIC > > chip? Perhaps, but I'm not aware of anyone putting four NICs on one > > chip. > > More evidence - the description claims it uses the RTL8139D and > RTL8305SB chipsets. The RTL8139D chipset is obviously the NIC, the > RTL8305B chipset is a five port switch: right again - 1 nic and a build-in switch. ...would be too cheap for a "real" quad-nic :-) -- Andre Ruppert
Re: 4port Realtek nic
On Thu, 16 Jun 2005 02:08:32 -0400 (EDT) Ted Unangst <[EMAIL PROTECTED]> wrote: > On Wed, 15 Jun 2005, Steven Bowers wrote: > > > Compgeeks is offering a 4port RTL8139D nic for an attractive price. > > I know the 8139 chipset is supported, not quite so sure of the > > 8138D. Can anyone speak for these cards? The price is nice and a > > 4port nic would be very handy. > > re should almost certainly work with it. may not attach because the > id is missing, but that's easy to fix. > It worksI used this nic several times...re is right -- Andre Ruppert Technische Leitung [EMAIL PROTECTED] PGP public key ID 4D987794 ___ www.vision-net.de | www.ECMSvario.de | www.evoip.de ___ Vision Consulting Deutschland oHG Osterather Str. 7, D-50739 Kvln (Cologne) Fon: +49-221-9171533 Fax: +49-221-9171538 http://www.vision-net.de, [EMAIL PROTECTED] ___ Geschdftsf|hrende Gesellschafter: Dipl.-Inf. Stephan Krafft, Laura Krafft ___ Register: HRA 15151 - Amtsgericht Kvln Ust-IDNr: DE176186883 IBAN: DE14370502990191002182 Swift-Code: COKSDE33 ___ Disclaimer: http://disclaimer.vision-net.de ___
