Re: Unexpected port change inside STUN packet
Amazing, I can't believe it was something so simple. Thank you both for the response, now the PS3 is working as it should On 7/25/09, TorbjC8rn H. Orskaug wrote: > I had this issue with my PS3 aswell. Adding a rule like > > nat on $ext_if from $ps3 to any -> ($ext_if) static-port > > solved the issue on my end, YMMV. Apparently the ps3 didn't like > it if pf altered the source port in its packets. > -- Allegari nihil et allegatum non probare, paria sunt.
Re: PF: 3 NICS. 1 WAN, 2 LAN. How to manage each LAN open ports individually?
I apologize that my ruleset isnt very clear. Iam trying to put together a ruleset that will allow the following access: Outbound port 80 (web) & 53 (domain) from users at $int_if via $ext_if Outbound port 80 (web) & 53 (domain) & 443 (ssl) & 22 (ssh) from $int_if2 via $ext_if Thank you for the help. Andres
Re: PF: 3 NICS. 1 WAN, 2 LAN. How to manage each LAN open ports individually?
On Sun, Jul 26, 2009 at 12:58:08AM -0500, Andres Salazar wrote:
> I apologize that my ruleset isnt very clear. Iam trying to put together a
> ruleset that will allow the following access:
>
> Outbound port 80 (web) & 53 (domain) from users at $int_if via $ext_if
> Outbound port 80 (web) & 53 (domain) & 443 (ssl) & 22 (ssh) from $int_if2
> via $ext_if
Here's a basic ruleset that meets your requirements. Hasn't been tested
for syntax. Note that I make no effort to filter traffic between the
two internal segments. This would require a different approach (no set
skip on internal if's, pass in on the internal if's explicitly). There
are also no "pass out" rules for traffic originating from the firewall
itself, you'll probably want to add something for this.
ext_if = "re1"
int_if = "re0"
int_if2 = "re2"
set skip on { lo $int_if $int_if2 }
scrub in
nat on $ext_if inet proto { tcp udp } from $int_if:network to any \
-> ($ext_if)
nat on $ext_if inet proto { tcp udp } from $int_if2:network to any \
-> ($ext_if)
block all
pass out on $ext_if inet proto tcp from $int_if:network to any \
port { 53 80 }
pass out on $ext_if inet proto udp from $int_if:network to any \
port 53
pass out on $ext_if inet proto tcp from $int_if2:network to any \
port { 22 53 80 443 }
pass out on $ext_if inet proto udp from $int_if2:network to any \
port 53
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/
Re: PF: 3 NICS. 1 WAN, 2 LAN. How to manage each LAN open ports individually?
On Sat, Jul 25, 2009 at 9:23 PM, Jason Dixon wrote:
> On Sat, Jul 25, 2009 at 09:41:45PM -0500, Andres Salazar wrote:
>> Hello OpenBSD-misc,
>>
>> I have a newbie question in pf that Ive been trying to debug on what would
>> be wrong with my ruleset. Iam trying to have the users that are on $int_if
>> only have ports 80 & 52 opened out, and users on $int_if be able to have
>> less restrictions and more ports out. So far I have something like this
but
>> it isnt working:
>
> Allow me to be the first to say "RTFAQ".
>
>> ext_if = "re1"
>> int_if = "re0"
>> int_if2 = "re2"
>>
>>
>> set skip on lo
>>
>> scrub in
>>
>> nat on re1 from re0:network to any -> re1
>> nat on re1 from re2:network to any -> re1
>>
>> block all
>> pass quick on $ext_if // I have added this so that the firewall itself has
>> full internet access
>> #pass in quick on $int_if
>
> Here you're blocking all by default (inbound and outbound on all
> interfaces), but then you immediately "pass quick" (outbound *and*
> inbound) on your external interface. B Very wrong.
>
>> pass out log quick on $ext_if inet proto { tcp, udp } from ($ext_if) to
any
>> \
>> B B B port 53 keep state
>>
>> pass out log quick on $ext_if inet proto { tcp } from ($ext_if) to any \
>> B B B port 80 keep state
>
> Here you're passing outbound on your external interface for DNS and http
> traffic. B But a) you've already allowed everything on $ext_if so this is
> unnecessary, and b) you've never allowed any traffic from your internal
> interfaces.
>
> Honestly, I don't know *what* you're trying to accomplish because your
> description doesn't match anything in your ruleset. B Perhaps you can
> describe again what you're trying to do and what the differences are
> supposed to be between $int_if and $int_if2.
I think he has a few typos in his email that cause confusion. I think
what he wants is something like the following, which is not tested,
and I know this is a copout, but I'm tired and should not be doing
this:
/
--\
ext_if = "re1"
int_if = "re0" # only ports 53 and 80 allowed out
int_if2 = "re2" # no restrictions on outbound traffic
set skip on lo
match in all scrub (no-df) # XXX
# XXX I do not use NAT so leaving this to the experts
nat on re1 from re0:network to any -> re1
nat on re1 from re2:network to any -> re1
block all
pass out
pass in on $int_if2
pass in log on $int_if inet proto { tcp, udp } from any to any port { 53, 80
}
\
--/
He may need finer control over who from $int_if2 is allowed access to
the firewall.
--patrick
Re: PF: 3 NICS. 1 WAN, 2 LAN. How to manage each LAN open ports individually?
On Sat, Jul 25, 2009 at 09:41:45PM -0500, Andres Salazar wrote:
> Hello OpenBSD-misc,
>
> I have a newbie question in pf that Ive been trying to debug on what would
> be wrong with my ruleset. Iam trying to have the users that are on $int_if
> only have ports 80 & 52 opened out, and users on $int_if be able to have
> less restrictions and more ports out. So far I have something like this but
> it isnt working:
Allow me to be the first to say "RTFAQ".
> ext_if = "re1"
> int_if = "re0"
> int_if2 = "re2"
>
>
> set skip on lo
>
> scrub in
>
> nat on re1 from re0:network to any -> re1
> nat on re1 from re2:network to any -> re1
>
> block all
> pass quick on $ext_if // I have added this so that the firewall itself has
> full internet access
> #pass in quick on $int_if
Here you're blocking all by default (inbound and outbound on all
interfaces), but then you immediately "pass quick" (outbound *and*
inbound) on your external interface. Very wrong.
> pass out log quick on $ext_if inet proto { tcp, udp } from ($ext_if) to any
> \
> port 53 keep state
>
> pass out log quick on $ext_if inet proto { tcp } from ($ext_if) to any \
> port 80 keep state
Here you're passing outbound on your external interface for DNS and http
traffic. But a) you've already allowed everything on $ext_if so this is
unnecessary, and b) you've never allowed any traffic from your internal
interfaces.
Honestly, I don't know *what* you're trying to accomplish because your
description doesn't match anything in your ruleset. Perhaps you can
describe again what you're trying to do and what the differences are
supposed to be between $int_if and $int_if2.
--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net/
PF: 3 NICS. 1 WAN, 2 LAN. How to manage each LAN open ports individually?
Hello OpenBSD-misc,
I have a newbie question in pf that Ive been trying to debug on what would
be wrong with my ruleset. Iam trying to have the users that are on $int_if
only have ports 80 & 52 opened out, and users on $int_if be able to have
less restrictions and more ports out. So far I have something like this but
it isnt working:
ext_if = "re1"
int_if = "re0"
int_if2 = "re2"
set skip on lo
scrub in
nat on re1 from re0:network to any -> re1
nat on re1 from re2:network to any -> re1
block all
pass quick on $ext_if // I have added this so that the firewall itself has
full internet access
#pass in quick on $int_if
pass out log quick on $ext_if inet proto { tcp, udp } from ($ext_if) to any
\
port 53 keep state
pass out log quick on $ext_if inet proto { tcp } from ($ext_if) to any \
port 80 keep state
I appreciate the help...
Andres
Sun Sparc64 problems
Howdy? I recently got hold of an Ultra-5 with 128mb. By various means I've managed to upgrad the prom to "*latest" and everything appeared to install ok. So now I simply cannot boot from the IDE disk I installed it on. I can boot from the install cd and mount this disk as can be seen from the included files (seperated here with the token asdf are devls.txt, disklabel.txt, dmesg.txt, ifconfig-a.txt, mount.txt) If anyone can shed some light on this for me I'd appreciate it. Thanks, Dhu devls.txt total 20 -rw-r--r-- 1 root wheel 9297 Mar 1 01:22 MAKEDEV crw--- 1 root wheel 120, 0 Mar 1 01:22 bio crw--- 1 root wheel 105, 0 Mar 1 01:22 bpf0 brw-r- 1 root operator 18, 0 Mar 1 01:22 cd0a brw-r- 1 root operator 18, 2 Mar 1 01:22 cd0c crw--- 1 root wheel 0, 0 Jul 26 00:48 console crw-rw 1 root operator 18, 3 Mar 1 01:22 enrst0 brw-rw 1 root operator 11, 3 Mar 1 01:22 enst0 crw-rw 1 root operator 18, 2 Mar 1 01:22 erst0 brw-rw 1 root operator 11, 2 Mar 1 01:22 est0 brw-r- 1 root operator 16, 0 Mar 1 01:22 fd0a brw-r- 1 root operator 16, 1 Mar 1 01:22 fd0b brw-r- 1 root operator 16, 2 Mar 1 01:22 fd0c brw-r- 1 root operator 16, 8 Mar 1 01:22 fd0i crw--- 1 root wheel 16, 0 Mar 1 01:22 klog crw-r- 1 root kmem3, 1 Mar 1 01:22 kmem crw-r- 1 root kmem 76, 0 Mar 1 01:22 ksyms crw-r- 1 root kmem3, 0 Mar 1 01:22 mem crw-rw 1 root operator 18, 1 Mar 1 01:22 nrst0 brw-rw 1 root operator 11, 1 Mar 1 01:22 nst0 crw-rw-rw- 1 root wheel 3, 2 Mar 1 01:22 null crw-r- 1 root kmem 70, 0 Mar 1 01:22 openprom crw-r- 1 root operator 58, 0 Mar 1 01:22 rcd0a crw-r- 1 root operator 58, 2 Mar 1 01:22 rcd0c brw-r- 1 root operator5, 0 Mar 1 01:22 rd0a brw-r- 1 root operator5, 2 Mar 1 01:22 rd0c crw-r- 1 root operator 54, 0 Mar 1 01:22 rfd0a crw-r- 1 root operator 54, 1 Mar 1 01:22 rfd0b crw-r- 1 root operator 54, 2 Mar 1 01:22 rfd0c crw-r- 1 root operator 54, 8 Mar 1 01:22 rfd0i crw-r- 1 root operator 61, 0 Mar 1 01:22 rrd0a crw-r- 1 root operator 61, 2 Mar 1 01:22 rrd0c crw-r- 1 root operator 17, 0 Mar 1 01:22 rsd0a crw-r- 1 root operator 17, 1 Mar 1 01:22 rsd0b crw-r- 1 root operator 17, 2 Mar 1 01:22 rsd0c crw-r- 1 root operator 17, 3 Mar 1 01:22 rsd0d crw-r- 1 root operator 17, 4 Mar 1 01:22 rsd0e crw-r- 1 root operator 17, 5 Mar 1 01:22 rsd0f crw-r- 1 root operator 17, 6 Mar 1 01:22 rsd0g crw-r- 1 root operator 17, 7 Mar 1 01:22 rsd0h crw-r- 1 root operator 17, 8 Mar 1 01:22 rsd0i crw-r- 1 root operator 17, 9 Mar 1 01:22 rsd0j crw-r- 1 root operator 17, 10 Mar 1 01:22 rsd0k crw-r- 1 root operator 17, 11 Mar 1 01:22 rsd0l crw-r- 1 root operator 17, 12 Mar 1 01:22 rsd0m crw-r- 1 root operator 17, 13 Mar 1 01:22 rsd0n crw-r- 1 root operator 17, 14 Mar 1 01:22 rsd0o crw-r- 1 root operator 17, 15 Mar 1 01:22 rsd0p crw-r- 1 root operator 17, 16 Mar 1 01:22 rsd1a crw-r- 1 root operator 17, 17 Mar 1 01:22 rsd1b crw-r- 1 root operator 17, 18 Mar 1 01:22 rsd1c crw-r- 1 root operator 17, 19 Mar 1 01:22 rsd1d crw-r- 1 root operator 17, 20 Mar 1 01:22 rsd1e crw-r- 1 root operator 17, 21 Mar 1 01:22 rsd1f crw-r- 1 root operator 17, 22 Mar 1 01:22 rsd1g crw-r- 1 root operator 17, 23 Mar 1 01:22 rsd1h crw-r- 1 root operator 17, 24 Mar 1 01:22 rsd1i crw-r- 1 root operator 17, 25 Mar 1 01:22 rsd1j crw-r- 1 root operator 17, 26 Mar 1 01:22 rsd1k crw-r- 1 root operator 17, 27 Mar 1 01:22 rsd1l crw-r- 1 root operator 17, 28 Mar 1 01:22 rsd1m crw-r- 1 root operator 17, 29 Mar 1 01:22 rsd1n crw-r- 1 root operator 17, 30 Mar 1 01:22 rsd1o crw-r- 1 root operator 17, 31 Mar 1 01:22 rsd1p crw-r- 1 root operator 17, 32 Mar 1 01:22 rsd2a crw-r- 1 root operator 17, 33 Mar 1 01:22 rsd2b crw-r- 1 root operator 17, 34 Mar 1 01:22 rsd2c crw-r- 1 root operator 17, 35 Mar 1 01:22 rsd2d crw-r- 1 root operator 17, 36 Mar 1 01:22 rsd2e crw-r- 1 root operator 17, 37 Mar 1 01:22 rsd2f crw-r- 1 root operator 17, 38 Mar 1 01:22 rsd2g crw-r- 1 root operator 17, 39 Mar 1 01:22 rsd2h crw-r- 1 root operator 17, 40 Mar 1 01:22 rsd2i crw-r- 1 root operator 17, 41 Mar 1 01:22 rsd2j crw-r- 1 root operator 17, 42 Mar 1 01:22 rsd2k crw-r- 1 root operator 17, 43 Mar 1 01:22 rsd2l crw-r- 1 root operator 17, 44 Mar 1 01:22 rsd2m crw-r- 1 root op
Re: man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
On Sun, Jul 26, 2009 at 04:44:45AM +1100, leon zadorin wrote: > Man page for mount_vnd states: > " > The `c' partition of a vnd image should not be used. When a superblock > becomes damaged, fsck_ffs(8) needs information contained in the disklabel > to determine the location of alternate superblocks. This information is > not available when directly using the `c' partition, so checking the file > system image will fail. > " > > Also, the man page for newfs states: > " > Before running newfs or mount_mfs, the disk must be labeled using > disklabel(8). newfs builds a file system on the specified special de- > vice, basing its defaults on the information in the disk label. > " > > But... the man 5 disklabel states: > " > Note that when a disk has no real BSD disklabel the kernel creates a de- > fault label so that the disk can be used. > " > > And indeed, it would appear (or may be my brain is getting sleepy) > that, running newfs on a device (such as svnd0c or vnd0c) which has no > disklabel installed explicitly does work ok... > ... now -- if, as man page for mount_vnd states, fsck_ffs needs > disklabel info when superblock is damaged -- why would it have any > trouble getting the default label that kernel creates for the "disk" > automatically as per man 5 disklabel quote above (the very same info, > I presume that newfs uses when initializing the fs initially on an > image with no explicit label)? > again, i can't help much here. but creating a disklabel for the first time might be different to using an existing disklabel. so it could be, as the man page suggests, that the alternate superblock info is gleaned after the disk is in use. i dunno. anyone else? jmc
Re: vnconfig vs swapctl for regular files
On Sun, Jul 26, 2009 at 03:25:48AM +1100, leon zadorin wrote: > > In other words what are the advantages to using vnconfig for swapping > as opposed to just calling swapctl/swapon directly on a regular file? > Moreover, fstab also takes regular file for swap partitions just fine > and subsequent (implicit) call to swapon also appears to work just > fine... > > Does it have to do, may be, with earlier versions of swapctl not > working with regular files... or some other historical differences in > the early days? > i don't have any answers here... first off, swapctl is a bit ambiguous in referring to "swap devices and files". i'm guessing the document was corrected when it was noted that files could be used as well as devices for swap, but i could be off the money. then the vnd thing...maybe a relic from when swap was not encrypted by default. again i'm not sure. maybe someone can step in here and we can clear up the docs. jmc
Re: English and Spanish keyboard at same time?
Are you working with X, or shell only? Dani Chris Bennett escribis: I do most of my work in English, but I also do a small amount in Spanish. I have a Spanish keyboard, but when I tried hooking it up, didn't get what was on keys. Is there any way to change this dynamically so that I can switch back and forth easily? Chris Bennett
Re: ddclient man page ?
Hi Jean-Francois, jean-francois wrote on Sat, Jul 25, 2009 at 10:11:40PM +0200: > Am I allowed to assume that there is no security flaw within such > little peace of software? No, small software can have security flaws, too. But in this particular case, what exactly do you fear? - You do not need to run ddclient as a privileged user. So, compromising your system is very improbable. If you want to be paranoid, you can create a _ddclient user having write access to no files except /var/db/ddclient and use that one to run the ddclient daemon. - Information disclosure? The whole point of ddclient is publishing your IP address, so that's certainly not sensitive data. Any other sensitive data on your system should not be readable by random users, anyway. - Denial of service? Well, if your DynDNS provider chooses to, he can delete your account any time he wants, and then you won't be reachable via DNS any more. So, in case ddclient fails to update your address, that's no worse than the risk you are running when using dynamic DNS in the first place. So, dynamic DNS is not a concept you typically use for security-critical applications, and i don't think ddclient needs to cause major headaches security-wise, as long as you don't run it as root or some other privileged user, which you really shouldn't be doing. Yours, Ingo
Re: ddclient man page ?
Thanks for this answer. Am I allowed to assume that there is no security flaw within such little peace of software ? Le samedi 25 juillet 2009 C 18:16 +0200, Ingo Schwarze a C)crit : > Hi Jean-Francois, > > > Is this wise to use ddclient according to one's experience, > > Well, ddclient is rather low quality Perl code, but it does its job. > > Actually, regarding a DynDNS client, the quality of the code is less > important than the care it takes to avoid unnecessary updates, such > that you don't get banned by your DynDNS provider for performing > bogus updates and contributing to useless server load on their side. > In that respect, ddclient is so good that it is the number one > recommended client by dyndns.org. > > > or which dyn dns client is recommended within openbsd if else ? > > I don't think the choice of your DynDNS client needs to depend that > much on the operating system you use. On OpenBSD, ddclient runs well, > and the port is up to date and maintained (by Joerg Zinke). > So i would say, just go ahead and use it. > > > I can't find details about ddclient such as a man page ? > > No, last time i checked, there wasn't any manual page or other > stand-alone documentation. > > > Do we have to guess with the only ddclient.conf ? > > Yes, the sample configuration file is meant to be self-documenting, > and indeed, nearly everything you need to know is contained in there. > In case you do want to know more, read the ddclient Perl script itself, > it is very short. > > Yours, > Ingo
Summer Sale on Personalized Drinkware!
BargainMugs.com Summer Sales & Specials CoffeeMugs | GlassMugs | Stemware| Pubware| CandyJars | SpringWater | SportsBottles | TravelMugs | PictureMugs ) 2009 Bargainmugs.com PO Box 523 Cazenovia, NY13035 Call us at 1.866.632.2188 supp...@bargainmugs.com To unsubscribe from BargainMugs.com Sales & Specials and othermarketing-related communications from BargainMugs.com, reply with "Remove"as the subject line.
Re: Unexpected port change inside STUN packet
I had this issue with my PS3 aswell. Adding a rule like nat on $ext_if from $ps3 to any -> ($ext_if) static-port solved the issue on my end, YMMV. Apparently the ps3 didn't like it if pf altered the source port in its packets.
man pages conflict or clarification for mount_vnd, newfs and man 5 disklabel
Man page for mount_vnd states: " The `c' partition of a vnd image should not be used. When a superblock becomes damaged, fsck_ffs(8) needs information contained in the disklabel to determine the location of alternate superblocks. This information is not available when directly using the `c' partition, so checking the file system image will fail. " Also, the man page for newfs states: " Before running newfs or mount_mfs, the disk must be labeled using disklabel(8). newfs builds a file system on the specified special de- vice, basing its defaults on the information in the disk label. " But... the man 5 disklabel states: " Note that when a disk has no real BSD disklabel the kernel creates a de- fault label so that the disk can be used. " And indeed, it would appear (or may be my brain is getting sleepy) that, running newfs on a device (such as svnd0c or vnd0c) which has no disklabel installed explicitly does work ok... ... now -- if, as man page for mount_vnd states, fsck_ffs needs disklabel info when superblock is damaged -- why would it have any trouble getting the default label that kernel creates for the "disk" automatically as per man 5 disklabel quote above (the very same info, I presume that newfs uses when initializing the fs initially on an image with no explicit label)? For example, wrt alternate superblock issues during fskc, the man page for newfs says: " -S sector-size The size of a sector in bytes (almost never anything but 512). Changing this is useful only when using newfs to build a file system whose raw image will eventually be used on a different type of disk than the one on which it is initially created (for example on a write-once disk). Note that chang- ing this from its default will make it impossible for fsck(8) to find the alternate superblocks if the standard superblock is lost. " Now, if the default disklabel (created by kernel, on the fly so to speak) provides info for the sector size (which is used by newfs during initializing, and by fsck when checking/restoring/fixing, the fs) then why would it still be bad to use the "c" partition of svnd/vnd? Kind regards Leon.
vnconfig vs swapctl for regular files
Hi, Man pages for vnconfig state that one of the useful things for "vnd" devices (not svnd ones) is to make them be used for swap. Given that vnconfig associates a vnd device with a regular file -- the above comments reduce to allowing one to use regular file as a swap space... only... why would one do all of this when swapctl/swapon accept regular file as arg anyway? In other words what are the advantages to using vnconfig for swapping as opposed to just calling swapctl/swapon directly on a regular file? Moreover, fstab also takes regular file for swap partitions just fine and subsequent (implicit) call to swapon also appears to work just fine... Does it have to do, may be, with earlier versions of swapctl not working with regular files... or some other historical differences in the early days? Also, if there is no distinct advantage of using vnconfig's vnd for swap (vs swapctl)... what other uses are there for explicit '/dev/vnd' (not 'svnd') devices? Kind regards Leon.
Unexpected port change inside STUN packet
Hi all, I've been using OpenBSD as a gateway for quite a while now and recently I got a PS3, so I decided to connect it to the network. Unfortunately, it kept complaining that I had a restrictive type of NAT and that other people would not be able to connect to me. At first, I thought it was some problem with my router, but when I connected the PS3 directly to the router all connection tests were successful, so I tried this very simple pf.conf: # ext_if = "rl0" int_if = "rl1" # ps3 = "10.0.0.8" # nat on $ext_if from $int_if:network to any -> ($ext_if) # rdr on $ext_if proto udp from any to ($ext_if) port 1:65535 -> $ps3 port 1:65535 # pass all # Even with that I was getting a restrictive type of NAT, so I decide to capture the packets being sent and received by the PS3 when it was doing the connection test both when connected directly to the router and when connected to the OpenBSD box. After comparing the packets I noticed something that could be the cause of the connection error. This is a packet when the connection is successful No. TimeSourceDestination Protocol Info 171 33.894835 198.107.158.129 192.168.1.3 STUN Message: Binding Response Frame 171 (122 bytes on wire, 122 bytes captured) Ethernet II, Src: D-Link_e1:b9:00 (00:1b:11:e1:b9:00), Dst: SonyComp_96:61:25 (00:1f:a7:96:61:25) Internet Protocol, Src: 198.107.158.129 (198.107.158.129), Dst: 192.168.1.3 (192.168.1.3) User Datagram Protocol, Src Port: stun (3478), Dst Port: 50526 (50526) Source port: stun (3478) Destination port: 50526 (50526) Length: 88 Checksum: 0xe9db [validation disabled] [Good Checksum: False] [Bad Checksum: False] Simple Traversal of UDP Through NAT [Request In: 170] [Time: 0.140815000 seconds] Message Type: Binding Response (0x0101) Message Length: 0x003c Message Transaction ID: BCEA76A6F4EAEE3ABFEA173E40579CBC Attributes Attribute: SOURCE-ADDRESS Attribute: CHANGED-ADDRESS Attribute: XOR_MAPPED_ADDRESS Attribute Type: XOR_MAPPED_ADDRESS (0x8020) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port (XOR-d): 31156 [Port: 50526] IP (XOR-d): 117.178.149.236 (117.178.149.236) [IP: 201.88.227.74 (201.88.227.74)] Attribute: MESSAGE-INTEGRITY # And this is a packet when the connection fails # No. TimeSourceDestination Protocol Info 162 36.836648 198.107.157.137 10.0.0.8 STUN Message: Binding Response Frame 162 (122 bytes on wire, 122 bytes captured) Ethernet II, Src: CnetTech_67:99:f8 (00:08:a1:67:99:f8), Dst: SonyComp_96:61:25 (00:1f:a7:96:61:25) Internet Protocol, Src: 198.107.157.137 (198.107.157.137), Dst: 10.0.0.8 (10.0.0.8) User Datagram Protocol, Src Port: stun (3478), Dst Port: 50516 (50516) Source port: stun (3478) Destination port: 50516 (50516) Length: 88 Checksum: 0x6f8f [validation disabled] [Good Checksum: False] [Bad Checksum: False] Simple Traversal of UDP Through NAT [Request In: 161] [Time: 0.133701000 seconds] Message Type: Binding Response (0x0101) Message Length: 0x003c Message Transaction ID: 0FDF0B74DA2676EC4751BFB3AE4CBAC2 Attributes Attribute: SOURCE-ADDRESS Attribute: CHANGED-ADDRESS Attribute: XOR_MAPPED_ADDRESS Attribute Type: XOR_MAPPED_ADDRESS (0x8020) Attribute Length: 8 Protocol Family: IPv4 (0x0001) Port (XOR-d): 50030 [Port: 52401] IP (XOR-d): 198.135.232.62 (198.135.232.62) [IP: 201.88.227.74 (201.88.227.74)] Attribute: MESSAGE-INTEGRITY # On the successful packet the port number inside the XOR_MAPPED_ADDRESS attribute is the same as the Destination port of the packet, on the failed connection those ports are different. What could be the cause of this? Any help is appreciated. I have posted the full packets here: Request (Successful): http://paste2.org/p/337420 Response (Successful): http://paste2.org/p/337422 Request (Failure): http://paste2.org/p/337424 Response (Failure): http://paste2.org/p/337426 Thanks in advance -- Allegari nihil et allegatum non probare, paria sunt.
Re: ddclient man page ?
Hi Jean-Francois, > Is this wise to use ddclient according to one's experience, Well, ddclient is rather low quality Perl code, but it does its job. Actually, regarding a DynDNS client, the quality of the code is less important than the care it takes to avoid unnecessary updates, such that you don't get banned by your DynDNS provider for performing bogus updates and contributing to useless server load on their side. In that respect, ddclient is so good that it is the number one recommended client by dyndns.org. > or which dyn dns client is recommended within openbsd if else ? I don't think the choice of your DynDNS client needs to depend that much on the operating system you use. On OpenBSD, ddclient runs well, and the port is up to date and maintained (by Joerg Zinke). So i would say, just go ahead and use it. > I can't find details about ddclient such as a man page ? No, last time i checked, there wasn't any manual page or other stand-alone documentation. > Do we have to guess with the only ddclient.conf ? Yes, the sample configuration file is meant to be self-documenting, and indeed, nearly everything you need to know is contained in there. In case you do want to know more, read the ddclient Perl script itself, it is very short. Yours, Ingo
ddclient man page ?
Hello, Is this wise to use ddclient according to one's experience, or which dyn dns client is recommended within openbsd if else ? I can't find details about ddclient such as a man page ? Do we have to guess with the only ddclient.conf ? Thanks
Re: /bsd: pf: wire key attach failed on all: 89 in wire
On Mon, Jul 20, 2009 at 10:51:24AM +0200, Holger Glaess wrote: > hi > first all for the answer at my last question. > > now can someone explain me what kind of error this is ? > > Jul 17 05:59:56 sun-fw1 /bsd: pf: wire key attach failed on all: 89 in > wire: xxx.xx.xxx.xxx 224.0.0.5 1:0 > > > carp wroks well but i had the problem that the rules dosen't really work, > first after an pfctl -Fall -f pf.conf seem'm to be ok ( the error was > also gone ). Just out of curiosity, would it be possible for you to post the relevant hostname.carp* and related hostname.if* files for the physical interfaces that are associated to the carp interfaces ? I am curious to see if you are running into an issue I ran across a short while ago. Also, dmesg output from the machines in question would be very useful ? -- Mathieu Sauve-Frankel
