Iked windows client using certificates?

[Justin Mayes]

Hello everyone

Just wanted to check my sanity after so many days. I have ikev2 setup working 
for windows machine for a long time using the following. So, to repeat this 
works, it connects fine.

ikev2 passive esp \
from 0.0.0.0/0 to 10.0.5.0/24 \
peer any local 50.247.187.177 \
srcid 50.247.187.177 \
config address 10.0.5.0/24

now I have a second windows client with a different certificate that I also 
want to connect at the same time but client B will disconnect client A. I need 
to add a dstid to this config to make specific entries for each machine I 
believe using ASN1_DN such as this? Or is there better way for clients with no 
fixed IP or FQDN?


ikev2 passive esp \
from 0.0.0.0/0 to 10.0.5.0/24 \
peer any local 50.247.187.177 \
srcid 50.247.187.177 \
dstid 
/C=US/ST=Illinois/L=HomeTown/O=OpenBSD/OU=iked/CN=myhostnameA.local/emailAddress=myem...@email.com
 \
config address 10.0.5.0/24

ikev2 passive esp \
from 0.0.0.0/0 to 10.0.5.0/24 \
peer any local 50.247.187.177 \
srcid 50.247.187.177 \
dstid 
/C=US/ST=Illinois/L=HomeTown/O=OpenBSD/OU=iked/CN=myhostnameB.local/emailAddress=myem...@email.com
 \
config address 10.0.5.0/24




The problem is that no dstid format I can find will work. Once I add dstid it 
fails to connect each time. Can someone help me here? Shouldn't this be 
possible or am I reading the man page wrong. I'm certain the spelling is 
correct and matches to the cert. The breakdown appears to be around here

Not working : Iked -dvv with ASN1_DN DSTID specified in iked.conf
ca_setauth: using SIG (RFC7427)
ca_setauth: auth length 393
ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG


Working : iked -dvv with no DSTID specified in iked.conf
ca_setauth: switching SIG to RSA_SIG(*)
ca_setauth: auth length 393
ikev2_msg_auth: initiator auth data length 1156
ikev2_msg_authverify: method RSA_SIG keylen 1028 type X509_CERT
ikev2_msg_authverify: authentication successful


J

Re: "switching console to com0"

[Justin Mayes]

Thanks for the replies all. This was very helpful. To clarify I was building 
some firewalls and didn’t have ssh running, a monitor/keyboard onsite, or 
install media. Disabling the serial port in the bios works though.

J

-Original Message-
From: Dahlberg, David [mailto:david.dahlb...@fkie.fraunhofer.de]
Sent: Tuesday, October 17, 2017 3:30 AM
To: Justin Mayes <jma...@careered.com>
Subject: Re: [misc] "switching console to com0"

Am Dienstag, den 17.10.2017, 04:03 +0000 schrieb Justin Mayes:
> Greetings all - what does one do when during the install you set the 
> default console to com0 and now your serial cable is not working?

Many possibilities:

- You ssh into the machine
- You just wait until booting has ended and the other ttys are started
- You boot the system from an external medium and edit boot.conf
- You type blindly (hoping that sending characters still works)
- You remove the serial port from your box (BIOS/EFI, PCI-Card)
  so that it is not discovered and /boot wont switch to it
  ... Or add an IMPI/iLO/etc "serial" port and make it become com0
- You reinstall the system
  ... from your backups (I guess you have them at hand, right? ;-)


And finally there is one possibility left. But you probably don't want to go 
into that. It is not for the faint hearted.

- Go buy yourself a new serial cable

Cheers
David

"switching console to com0"

[Justin Mayes]

Greetings all - what does one do when during the install you set the default 
console to com0 and now your serial cable is not working? I cannot login to set 
the default console back to use the keyboard and monitor. Instead of the boot 
prompt where I can normally change settings and/or enter single user mode I 
just get the message "switching console to com0" immediately without any delay 
to enter boot commands. Thanks for your time.

J

Re: ispec - PSK - issues

[Justin Mayes]

Hello all - 

I was also recently trying to do a simple ipsec/l2tp vpn. I found that it works 
fine for everything except my android 5.1.1 device. The odd thing is that when 
I watch the log and/or isakmpd output I can see it connect fine, authenticate 
to l2tp and so on then it immediately disconnects and says that the client 
caused the disconnection. When I google I see all sorts of issues with android 
but mostly related to 6+. I can even see in the log that npppd successfully 
authenticates my android and creates a tunnel, android just kills it all after 
1 second for some reason. Can anyone confirm that android 5.1.1 works with 
openbsd ipsec/l2tp before I spend more hours trying to figure out why just this 
android device is not working? Here is that tail of the log where l2tp is 
killed right after starting.


npppd[860]: ppp id=20 layer=base logtype=TUNNELSTART user="mike" duration=0sec 
layer2=L2TP layer2from=x.x.x.x:1701 auth=MS-CHAP-V2  ip=10.0.0.103 iface=pppx0
npppd[860]: ppp id=20 layer=base Using pipex=yes
npppd[860]: ppp id=20 layer=lcp terminated by peer
npppd[860]: l2tpd ctrl=21 RecvStopCCN result=GENERAL/1 error=none/0 
tunnel_id=13671 message=""
npppd[860]: l2tpd ctrl=21 call=1 SendCDN result=ADMINISTRATIVE_REASON/3
npppd[860]: l2tpd ctrl=21 call=1 logtype=PPPUnbind
npppd[860]: ppp id=20 layer=base logtype=TUNNELUSAGE user="mike" duration=0sec 
layer2=L2TP layer2from=x.x.x.x:1701 auth=MS-CHAP-V2 data_in=213bytes,9packets 
data_out=219bytes,10packets error_in=0 error_out=0 mppe=no iface=pppx0
npppd[860]: l2tpd ctrl=21 Received CDN in 'cleanup-wait' state
npppd[860]: l2tpd ctrl=21 logtype=Finished


Justin


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Raul 
Miller
Sent: Tuesday, July 26, 2016 7:14 AM
To: Maurice Janssen 
Cc: Steve Clement ; OpenBSD general usage list 

Subject: Re: ispec - PSK - issues

On Tue, Jul 26, 2016 at 2:08 AM, Maurice Janssen  wrote:
>>https://code.google.com/p/android/issues/detail?id=196939
>
> Yeah, that's the link I wanted to send.  Somehow I managed to copy the 
> wrong link in my previous email.

I have been seeing a lot of copy errors myself, where I performed the 
keyboard action to trigger a copy but paste gives me something from an older 
context.

I'm sure a lot of people put a lot of time into making things work this way...

--
Raul

Re: NATing out enc0 traffic

[Justin Mayes]

I have this working. After learning more about route vs policy ipsec tunnels I 
added a policy for 'any' to 10.x and return traffic from the net is now passed 
back. I will go back to my cave now


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Friday, May 29, 2015 11:10 AM
To: misc@openbsd.org
Subject: Re: NATing out enc0 traffic

I think I am understanding this better after some more reading. My ipsec tunnel 
just connects the two subnets and when my nat traffic returns from the internet 
it does not match the policy for the tunnel because the source address is not 
192.x. What I need is some tunneling protocol that I can route like pptp or 
l2tp which is what npppd is for. I do not have access to configure the amazon 
side of the vpn for pptp or l2tp so I do not think this is not going to be 
possible. That seems odd. I assumed this would be a common setup

-Original Message-
From: Justin Mayes 
Sent: Thursday, May 28, 2015 1:52 PM
To: misc@openbsd.org
Subject: RE: NATing out enc0 traffic

I just wanted to send an update based on some feedback. My subject is 
misleading so let me clarify. I'm not attempting to nat between the networks on 
either side of the vpn. For examples sake assume 192.168.0.0/24 on one side of 
tunnel and 10.10.10.0/24 on the other.  I'm trying to allow servers on one side 
10.x of the tunnel to access the internet via the other side of the tunnel 
192.168.0.1. Egress works, 10.x client gets to the internet and replies come 
back. The return traffic comes back and the gateway drops it. I assume that pf 
translates it back to the 10.x address and has no route for that. I need it to 
go back through enc0. 

J

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, May 27, 2015 2:47 PM
To: misc@openbsd.org
Subject: NATing out enc0 traffic

Greetings everyone

I am playing with amazon virtual private clouds (VPC). I have set a few up. I 
have no issues connecting ipsec from openbsd  - amazon VPC. All of these VPCs 
so far have their own internet connection going out from amazon that works fine.


[OpenBSD]ipsec-[VPC]-Internet


Next I am setting up a VPC that has no internet gateway. Instead the default 
gateway is the vpn and all traffic is sent back through the ipsec tunnel and 
then out the local network gateway.

[Internet]
^
|
|
|
[OpenBSD]---ipsec--[VPC]


I added these relevant lines to pf.conf

Match out on $ext_if from !($ext_if:network) nat-to ($ext_if) pass quick on 
enc0 keep state (if-bound)

With tcpdump and pfctl  I can tell that traffic from the vpc (10.0.0.0/8) comes 
across the tunnel and gets NATed out. I can see that traffic leave the external 
interface and I can see the reply come back to the external interface. The 
reply never hits enc0 though and never makes it back to the client.  Is there 
another piece to the setup I am missing? I assume what I am trying to do is 
possible. I would appreciate any insight or advice anyone may have in regards 
to this type of setup.

J

Re: NATing out enc0 traffic

[Justin Mayes]

No problem. I guess I should add that I'm not NATing enc0 as my subject 
suggests. I just have the usual 'match out on $ext_if...' nat rule in pf.conf 
and a 'set skip on enc0'. The real solution was understanding that ipsec tunnel 
in openbsd doesn’t use the route table so looking for a way to 'static route' 
ipsec /enc0 is nonsensical. This lack of automatic routable ipsec interface is 
probably not a big deal to the community because you can just make your own 
tunnel to get a routable interface assuming you can config both sides. It's 
only a problem in cases like mine where the other end of the vpn gives you a 
take it leave it config. 

-Original Message-
From: Adam Van Ymeren [mailto:adam.v...@gmail.com] 
Sent: Monday, June 1, 2015 2:16 PM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: NATing out enc0 traffic

Thanks for posting your adventure.  I didn't have enough PF knowledge to help 
debug, but it was an interesting read.

On Mon, Jun 1, 2015 at 3:11 PM, Justin Mayes jma...@careered.com wrote:
 I have this working. After learning more about route vs policy ipsec tunnels 
 I added a policy for 'any' to 10.x and return traffic from the net is now 
 passed back. I will go back to my cave now


 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin Mayes
 Sent: Friday, May 29, 2015 11:10 AM
 To: misc@openbsd.org
 Subject: Re: NATing out enc0 traffic

 I think I am understanding this better after some more reading. My 
 ipsec tunnel just connects the two subnets and when my nat traffic 
 returns from the internet it does not match the policy for the tunnel 
 because the source address is not 192.x. What I need is some tunneling 
 protocol that I can route like pptp or l2tp which is what npppd is 
 for. I do not have access to configure the amazon side of the vpn for 
 pptp or l2tp so I do not think this is not going to be possible. That 
 seems odd. I assumed this would be a common setup

 -Original Message-
 From: Justin Mayes
 Sent: Thursday, May 28, 2015 1:52 PM
 To: misc@openbsd.org
 Subject: RE: NATing out enc0 traffic

 I just wanted to send an update based on some feedback. My subject is 
 misleading so let me clarify. I'm not attempting to nat between the networks 
 on either side of the vpn. For examples sake assume 192.168.0.0/24 on one 
 side of tunnel and 10.10.10.0/24 on the other.  I'm trying to allow servers 
 on one side 10.x of the tunnel to access the internet via the other side of 
 the tunnel 192.168.0.1. Egress works, 10.x client gets to the internet and 
 replies come back. The return traffic comes back and the gateway drops it. I 
 assume that pf translates it back to the 10.x address and has no route for 
 that. I need it to go back through enc0.

 J

 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin Mayes
 Sent: Wednesday, May 27, 2015 2:47 PM
 To: misc@openbsd.org
 Subject: NATing out enc0 traffic

 Greetings everyone

 I am playing with amazon virtual private clouds (VPC). I have set a few up. I 
 have no issues connecting ipsec from openbsd  - amazon VPC. All of these 
 VPCs so far have their own internet connection going out from amazon that 
 works fine.


 [OpenBSD]ipsec-[VPC]-Internet


 Next I am setting up a VPC that has no internet gateway. Instead the default 
 gateway is the vpn and all traffic is sent back through the ipsec tunnel and 
 then out the local network gateway.

 [Internet]
 ^
 |
 |
 |
 [OpenBSD]---ipsec--[VPC]


 I added these relevant lines to pf.conf

 Match out on $ext_if from !($ext_if:network) nat-to ($ext_if) pass 
 quick on enc0 keep state (if-bound)

 With tcpdump and pfctl  I can tell that traffic from the vpc (10.0.0.0/8) 
 comes across the tunnel and gets NATed out. I can see that traffic leave the 
 external interface and I can see the reply come back to the external 
 interface. The reply never hits enc0 though and never makes it back to the 
 client.  Is there another piece to the setup I am missing? I assume what I am 
 trying to do is possible. I would appreciate any insight or advice anyone may 
 have in regards to this type of setup.

 J

Re: NATing out enc0 traffic

[Justin Mayes]

I think I am understanding this better after some more reading. My ipsec tunnel 
just connects the two subnets and when my nat traffic returns from the internet 
it does not match the policy for the tunnel because the source address is not 
192.x. What I need is some tunneling protocol that I can route like pptp or 
l2tp which is what npppd is for. I do not have access to configure the amazon 
side of the vpn for pptp or l2tp so I do not think this is not going to be 
possible. That seems odd. I assumed this would be a common setup

-Original Message-
From: Justin Mayes 
Sent: Thursday, May 28, 2015 1:52 PM
To: misc@openbsd.org
Subject: RE: NATing out enc0 traffic

I just wanted to send an update based on some feedback. My subject is 
misleading so let me clarify. I'm not attempting to nat between the networks on 
either side of the vpn. For examples sake assume 192.168.0.0/24 on one side of 
tunnel and 10.10.10.0/24 on the other.  I'm trying to allow servers on one side 
10.x of the tunnel to access the internet via the other side of the tunnel 
192.168.0.1. Egress works, 10.x client gets to the internet and replies come 
back. The return traffic comes back and the gateway drops it. I assume that pf 
translates it back to the 10.x address and has no route for that. I need it to 
go back through enc0. 

J

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, May 27, 2015 2:47 PM
To: misc@openbsd.org
Subject: NATing out enc0 traffic

Greetings everyone

I am playing with amazon virtual private clouds (VPC). I have set a few up. I 
have no issues connecting ipsec from openbsd  - amazon VPC. All of these VPCs 
so far have their own internet connection going out from amazon that works fine.


[OpenBSD]ipsec-[VPC]-Internet


Next I am setting up a VPC that has no internet gateway. Instead the default 
gateway is the vpn and all traffic is sent back through the ipsec tunnel and 
then out the local network gateway.

[Internet]
^
|
|
|
[OpenBSD]---ipsec--[VPC]


I added these relevant lines to pf.conf

Match out on $ext_if from !($ext_if:network) nat-to ($ext_if) pass quick on 
enc0 keep state (if-bound)

With tcpdump and pfctl  I can tell that traffic from the vpc (10.0.0.0/8) comes 
across the tunnel and gets NATed out. I can see that traffic leave the external 
interface and I can see the reply come back to the external interface. The 
reply never hits enc0 though and never makes it back to the client.  Is there 
another piece to the setup I am missing? I assume what I am trying to do is 
possible. I would appreciate any insight or advice anyone may have in regards 
to this type of setup.

J

Re: NATing out enc0 traffic

[Justin Mayes]

I just wanted to send an update based on some feedback. My subject is 
misleading so let me clarify. I'm not attempting to nat between the networks on 
either side of the vpn. For examples sake assume 192.168.0.0/24 on one side of 
tunnel and 10.10.10.0/24 on the other.  I'm trying to allow servers on one side 
10.x of the tunnel to access the internet via the other side of the tunnel 
192.168.0.1. Egress works, 10.x client gets to the internet and replies come 
back. The return traffic comes back and the gateway drops it. I assume that pf 
translates it back to the 10.x address and has no route for that. I need it to 
go back through enc0. 

J

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, May 27, 2015 2:47 PM
To: misc@openbsd.org
Subject: NATing out enc0 traffic

Greetings everyone

I am playing with amazon virtual private clouds (VPC). I have set a few up. I 
have no issues connecting ipsec from openbsd  - amazon VPC. All of these VPCs 
so far have their own internet connection going out from amazon that works fine.


[OpenBSD]ipsec-[VPC]-Internet


Next I am setting up a VPC that has no internet gateway. Instead the default 
gateway is the vpn and all traffic is sent back through the ipsec tunnel and 
then out the local network gateway.

[Internet]
^
|
|
|
[OpenBSD]---ipsec--[VPC]


I added these relevant lines to pf.conf

Match out on $ext_if from !($ext_if:network) nat-to ($ext_if) pass quick on 
enc0 keep state (if-bound)

With tcpdump and pfctl  I can tell that traffic from the vpc (10.0.0.0/8) comes 
across the tunnel and gets NATed out. I can see that traffic leave the external 
interface and I can see the reply come back to the external interface. The 
reply never hits enc0 though and never makes it back to the client.  Is there 
another piece to the setup I am missing? I assume what I am trying to do is 
possible. I would appreciate any insight or advice anyone may have in regards 
to this type of setup.

J

NATing out enc0 traffic

[Justin Mayes]

Greetings everyone

I am playing with amazon virtual private clouds (VPC). I have set a few up. I
have no issues connecting ipsec from openbsd  - amazon VPC. All of these
VPCs so far have their own internet connection going out from amazon that
works fine.


[OpenBSD]ipsec-[VPC]-Internet


Next I am setting up a VPC that has no internet gateway. Instead the default
gateway is the vpn and all traffic is sent back through the ipsec tunnel and
then out the local network gateway.

[Internet]
^
|
|
|
[OpenBSD]---ipsec--[VPC]


I added these relevant lines to pf.conf

Match out on $ext_if from !($ext_if:network) nat-to ($ext_if)
pass quick on enc0 keep state (if-bound)

With tcpdump and pfctl  I can tell that traffic from the vpc (10.0.0.0/8)
comes across the tunnel and gets NATed out. I can see that traffic leave the
external interface and I can see the reply come back to the external
interface. The reply never hits enc0 though and never makes it back to the
client.  Is there another piece to the setup I am missing? I assume what I am
trying to do is possible. I would appreciate any insight or advice anyone may
have in regards to this type of setup.

J

Making tftp download large files from tftpd

[Justin Mayes]

I will spare you all the backstory but I found that tftp could not download
files over 32 mb by default from tftpd. I know you can pass blocksize to tftpd
to handle much larger files but I was originally working with a client where
this wasn't possible. Tftp protocol has 2 bytes for block number which put a
65535 limit on that. tftpd data doesn't care and will just roll that over back
to 0 and keep sending data. Tftp client fails when there is block number roll
over because it is tracking all the blocks with an int so ends up comparing
its block counter which is now at 65536 to what comes off the network, 0 and
quits. I updated the tftp client code to use same data type as the network
side structs are using  - u_int16_t. Now tftp counter rolls along with server
and can send file of any size with or without a blocksize change. I feel like
this is mostly pointless but doesn't hurt anything. Will gladly provide the
actuall diffs. I have to look into that process for openbsd but just wanted to
check with the group first in case there was a reason an int was used that I
do not understand.

J

Re: Shadow TCP stacks

[Justin Mayes]

On the contrary: it_will_  make it impossible for people to know what 
 _we_  are doing. This is not one system I'm talking about: it's 
 countless independent VPNs. No one person in the world will ever know 
 what_we_  are doing.

'countless independent VPNs' + 'a one-time pre-shared key' = big trouble

My advice - Torproject.org
Currently the best math/crypto based solution to provide private service 
hosting and anonymous browsing. Open source, peer reviewed, thoroughly abused 
by smart people and so on. Tor also solves the very real metadata problem this 
paper does not even address. 

Any code that makes it into the kernel introduces complexity must offset its 
long term cost with usefulness. I don't think this repackaged port knocking 
mess passes that test.

J

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Giancarlo Razzolini
Sent: Monday, October 20, 2014 7:34 AM
To: Ian Grant
Cc: Bret Lambert; OpenBSD general usage list
Subject: Re: Shadow TCP stacks

On 19-10-2014 21:01, Ian Grant wrote:
 On the contrary: it_will_  make it impossible for people to know what 
 _we_  are doing. This is not one system I'm talking about: it's 
 countless independent VPNs. No one person in the world will ever know 
 what_we_  are doing.
Except perhaps for the nations with mass surveillance capabilities.

 It's not security by obscurity, it's a one-time pre-shared key.
Well, the need for a PSK doesn't change the fact that you're trying to conceal 
something, but not making it inherently more secure.

 You think someone can analyse all the HTTP traffic in a country? So 
 what if they could? By the time they've analysed the dumps the service 
 won't be on that host anymore.
In what world do you live? Didn't you followed the news regarding Eduard 
Snowden disclosures? Not only it is possible to analyze all HTTP traffic on any 
given country, but it's also possible to analyze ALL traffic on any given 
country. This is exactly what NSA is doing and perhaps others also. Hell, even 
some companies such as akamai and others can see a great chunk of the internet 
traffic.

 The issue I am addressing is not privacy. You would know that if you 
 had read the Foundation paper:


http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html
Yes, you're not addressing *just* privacy. But your original post e-mail 
subject of shadow TCP stacks is misleading.
 Well, they don't have a choice, because OpenBSD is open source, or 
 haven't you heard?
Even if you did manage to create a nice patch, bug free, with great security 
and all, I don't ever see this getting into the OpenBSD source tree. And, as 
Henning, an OpenBSD developer, putted on a reply to you, you don't get to 
decide what they put into their source code tree. As I said before, focus on 
the proper development of good and strong cryptography, and you'll sure see 
your contributions get into OpenBSD, provided they are in the project's 
interest, of course.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Making tftp download large files from tftpd

[Justin Mayes]

Here is my diff to change the data type of the block variable so tftp can
handle tftpd block rollover when transferring large files.
May not be that useful but I'm just using something trivial (pun intended) to
learn the procedure.

J

From: Justin Mayes
Sent: Monday, October 20, 2014 9:26 AM
To: misc@openbsd.org
Subject: Making tftp download large files from tftpd

I will spare you all the backstory but I found that tftp could not download
files over 32 mb by default from tftpd. I know you can pass blocksize to tftpd
to handle much larger files but I was originally working with a client where
this wasn't possible. Tftp protocol has 2 bytes for block number which put a
65535 limit on that. tftpd data doesn't care and will just roll that over back
to 0 and keep sending data. Tftp client fails when there is block number roll
over because it is tracking all the blocks with an int so ends up comparing
its block counter which is now at 65536 to what comes off the network, 0 and
quits. I updated the tftp client code to use same data type as the network
side structs are using  - u_int16_t. Now tftp counter rolls along with server
and can send file of any size with or without a blocksize change. I feel like
this is mostly pointless but doesn't hurt anything. Will gladly provide the
actuall diffs. I have to look into that process for openbsd but just wanted to
check with the group first in case there was a reason an int was used that I
do not understand.

J

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of tftp.diff]

Re: Making tftp download large files from tftpd

[Justin Mayes]

I could. My original problem was with cisco rommon tftpdnld command as client 
failing talking to tftpd. I just notice the tftp client problem while testing 
locally. After this I intend to go back and make tftpd work with whatever cisco 
client is doing. Since that’s a two byte field in the rfc there is no way I 
know of that tftpd or any other server can get more than 65536 in there so all 
they can do is rollover. The only thing I can think is maybe cisco client 
starts at 1 rather than 0. A tcpdump will tell me in a little while. This is 
more of a learning experience for me. I want to go through motions of getting 
source, debugging some issue with gdb, updating the code, build and all that. 
I've done that many times in windows world but not in any unix like Oses. So 
far the exercise is a success in that I learned a ton and if that diff was 
worth anything to anyone, even better. Thanks for the tip tho James, its good 
advice.

J
-Original Message-
From: James A. Peltier [mailto:jpelt...@sfu.ca] 
Sent: Monday, October 20, 2014 5:34 PM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: Making tftp download large files from tftpd

- Original Message -
| I will spare you all the backstory but I found that tftp could not 
| download files over 32 mb by default from tftpd. I know you can pass 
| blocksize to tftpd to handle much larger files but I was originally 
| working with a client where this wasn't possible. Tftp protocol has 2 
| bytes for block number which put a
| 65535 limit on that. tftpd data doesn't care and will just roll that 
| over back to 0 and keep sending data. Tftp client fails when there is 
| block number roll over because it is tracking all the blocks with an 
| int so ends up comparing its block counter which is now at 65536 to 
| what comes off the network, 0 and quits. I updated the tftp client 
| code to use same data type as the network side structs are using  - 
| u_int16_t. Now tftp counter rolls along with server and can send file 
| of any size with or without a blocksize change. I feel like this is 
| mostly pointless but doesn't hurt anything. Will gladly provide the 
| actuall diffs. I have to look into that process for openbsd but just 
| wanted to check with the group first in case there was a reason an int 
| was used that I do not understand.
| 
| J

Or you could chainload iPXE to allow for the downloading of your file over HTTP 
which is much faster than TFTP to begin with.  This is indeed what we do.

--
James A. Peltier
IT Services - Research Computing Group
Simon Fraser University - Burnaby Campus
Phone   : 778-782-6573
Fax : 778-782-3045
E-Mail  : jpelt...@sfu.ca
Website : http://www.sfu.ca/itservices
Twitter : @sfu_rcg
Powering Engagement Through Technology

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

Thanks to both of you for the advice
Just to followup I ended up with the relayd 'routers' setup as described in man 
 page but with a script monitor rather than icmp. The monitor finds gateway for 
interface in route table and pings it with -I interface source address. Seems 
to work as desired. I also got it to work with ifstated but it seemed like more 
script and also a 2nd process when I have to run relayd for other purpose 
anyway. 


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Stuart Henderson
Sent: Friday, October 10, 2014 4:56 PM
To: misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

On 2014-10-09, Justin Mayes jma...@careered.com wrote:
 Ok I got it working. Here is what I did

 Enabled multipath routing (sysctl)
 Added the relayd anchor to pf.conf
 Created a relayd.conf with this in it

 gw1=fxp0
 gw2=fxp1

 table gateways { $gw1 ip ttl 1, $gw2 ip ttl 1 } router uplinks {
   route 0.0.0.0/0 
   forward to gateways check icmp
 }

Your relayd test here just pings your own interface's local IP addresses.
For example if fxp0's address is 10.0.0.2, it is pinging 10.0.0.2.
ifconfig fxp0 down will cause it to be detected, but it won't even notice you 
pulling out the cable. Also I don't believe it will track your dynamic address.

One thing you could do in your situation is to use a route-to for the 
connection where you have a static address, and use a probability
PF rule to load balance, allowing other traffic to be hit the normal default 
route.

Another thing you could do is to use multiple route tables, and similarly use 
pf rules to direct traffic to use one table or another.

For failover you can have some external checker (maybe run from ifstated, or 
maybe a simple shell script run from cron) that adjusts the PF ruleset as 
appropriate. You could either switch the whole ruleset out by pointing pfctl -f 
to a different file, or put the relevant route-to pieces in an anchor.

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

Ok I got it working. Here is what I did

Enabled multipath routing (sysctl)
Added the relayd anchor to pf.conf
Created a relayd.conf with this in it

gw1=fxp0
gw2=fxp1

table gateways { $gw1 ip ttl 1, $gw2 ip ttl 1 } 
router uplinks { 
route 0.0.0.0/0 
forward to gateways check icmp
}
Started relayd
Reloaded pf.conf

I then could see with 'relayctl show summary' my two gateways and their 'up' 
status as well as the default route to each with 'route show'. When I 'ifconfig 
down' one interface, 'relayctl show summary' showed it as down and then default 
route to it was removed automatically. Awesomeness.


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, October 8, 2014 10:56 PM
To: misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

I just watched Reyk's youtube. I'm going with relayd. I can see the 'routers' 
section in the man page for relayd to do what I want. 

http://www.youtube.com/watch?v=JtMxGslqGbM


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, October 8, 2014 10:04 PM
To: misc@openbsd.org
Subject: Route-to with a dynamic 'next hop'

Greetings all -

I have 2 internet connections. One of them is static IP, one is dynamic. I want 
to use both of them on my gateway. From the man pages and other docs I see the 
use of route-to in the pf.conf including the 'next-hop' that it requires. This 
is easy enough. Problem is that the next hop is hard coded IP in all examples. 
I need that next hop to get updated when my one WAN DHCP link is updated. I 
know about if:peer, if:broadcast, if:network ect but there is no if:gateway. 
Seems like you could have used dhclient-script to adjust pf config when ip 
changed but dhclient-script has been removed.  I also read that relayd has 
become the best option to accomplish this uplink load balancing in current 
versions of OpenBSD. I wanted to check with you all to make sure I'm not 
missing something basic with the load balanced uplink scenario in OpenBSD. As 
always, comments and suggestions are much appreciated.

J

Route-to dynamic next hop

[Justin Mayes]

I have 2 internet connections. One of them is static IP, one is dynamic. I
want to use both of them on my gateway. From the man pages and other docs I
see the use of route-to in the pf.conf including the 'next-hop' that it
requires. This is easy enough. Problem is that the next hop is hard coded IP
in all examples. I need that next hop to get updated when my one WAN DHCP link
is updated. I know about if:peer, if:broadcast, if:network ect but there is no
if:gateway. Seems like you could have used dhclient-script to adjust pf config
when ip changed but dhclient-script has been removed.  It also seems like
relayd has become the best option to accomplish this uplink load balancing. I
just wanted to check with you all to make sure I'm not missing something basic
with the load balanced uplink scenario in OpenBSD. As always, comments and
suggestions are much appreciated.

J

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

I did notice the problem with only detecting a LAN failure and was looking at a 
better monitor.  If I just used plain PF rules what would I use for the 
next-hop parameter to the route-to command? This IP is dynamic.


-Original Message-
From: Giancarlo Razzolini [mailto:grazzol...@gmail.com] 
Sent: Thursday, October 9, 2014 7:26 AM
To: Justin Mayes; misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

On 09-10-2014 02:58, Justin Mayes wrote:
 Ok I got it working. Here is what I did

 Enabled multipath routing (sysctl)
 Added the relayd anchor to pf.conf
 Created a relayd.conf with this in it

 gw1=fxp0
 gw2=fxp1

 table gateways { $gw1 ip ttl 1, $gw2 ip ttl 1 }
 router uplinks {
   route 0.0.0.0/0
   forward to gateways check icmp
 }
 Started relayd
 Reloaded pf.conf

 I then could see with 'relayctl show summary' my two gateways and their 'up' 
 status as well as the default route to each with 'route show'. When I 
 'ifconfig down' one interface, 'relayctl show summary' showed it as down and 
 then default route to it was removed automatically. Awesomeness.


 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
 Justin Mayes
 Sent: Wednesday, October 8, 2014 10:56 PM
 To: misc@openbsd.org
 Subject: Re: Route-to with a dynamic 'next hop'

 I just watched Reyk's youtube. I'm going with relayd. I can see the 'routers' 
 section in the man page for relayd to do what I want.

 http://www.youtube.com/watch?v=JtMxGslqGbM


 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
 Justin Mayes
 Sent: Wednesday, October 8, 2014 10:04 PM
 To: misc@openbsd.org
 Subject: Route-to with a dynamic 'next hop'

 Greetings all -

 I have 2 internet connections. One of them is static IP, one is dynamic. I 
 want to use both of them on my gateway. From the man pages and other docs I 
 see the use of route-to in the pf.conf including the 'next-hop' that it 
 requires. This is easy enough. Problem is that the next hop is hard coded IP 
 in all examples. I need that next hop to get updated when my one WAN DHCP 
 link is updated. I know about if:peer, if:broadcast, if:network ect but there 
 is no if:gateway. Seems like you could have used dhclient-script to adjust pf 
 config when ip changed but dhclient-script has been removed.  I also read 
 that relayd has become the best option to accomplish this uplink load 
 balancing in current versions of OpenBSD. I wanted to check with you all to 
 make sure I'm not missing something basic with the load balanced uplink 
 scenario in OpenBSD. As always, comments and suggestions are much appreciated.

 J

There is no need to use relayd. Plain pf rules would do the trick, even 
on you dynamic interface. The relayd conf you made will only detect 
failure at the LAN network level. It will not detect internet failure. 
For that you would need to add another checks through icmp to ping 
external ip addresses. Or a check script. There is also the option of 
using ifstated. As, for the rules part you could use the route-to direct 
to the interface.

Cheers

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

My understanding of route-to is that if the destination is not on same network 
as the 'route-to' interface, you need the second 'next hop' parameter. All 
examples I was seeing show pf.conf this way. Is that not right? I will test 
with just the interface name.



-Original Message-
From: Giancarlo Razzolini [mailto:grazzol...@gmail.com] 
Sent: Thursday, October 9, 2014 8:52 AM
To: Justin Mayes; misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

On 09-10-2014 10:16, Justin Mayes wrote:
 I did notice the problem with only detecting a LAN failure and was looking at 
 a better monitor.  If I just used plain PF rules what would I use for the 
 next-hop parameter to the route-to command? This IP is dynamic.

There is no next-hop. Just make your rule point to the interface. 
route-to (if). You can also make it route-to if. In either cases, you'd 
be better off using ifstated/relayd with anchors to dynamicaly change 
your rules, in case of link failures. Also, if possible, use snmp to 
query your modems/routers to determine the internet link availability.

Cheers

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

In Reyk's presentation he talks about this 
(http://www.youtube.com/watch?v=JtMxGslqGbM) @ 19:30 and describes the 'link 
balancer' functionality of relayd intended to do exactly what I want. It 
appears to work as described. In the presentation Reyk says relayd will check 
for upstream router availability but the conf example just pings the interface 
it appears. Sorry for all the babble but I am away from the location where I 
have 2 internet connections so I cannot test this stuff right now as I normally 
would.


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Thursday, October 9, 2014 9:05 AM
To: grazzol...@gmail.com; misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

My understanding of route-to is that if the destination is not on same network 
as the 'route-to' interface, you need the second 'next hop' parameter. All 
examples I was seeing show pf.conf this way. Is that not right? I will test 
with just the interface name.



-Original Message-
From: Giancarlo Razzolini [mailto:grazzol...@gmail.com]
Sent: Thursday, October 9, 2014 8:52 AM
To: Justin Mayes; misc@openbsd.org
Subject: Re: Route-to with a dynamic 'next hop'

On 09-10-2014 10:16, Justin Mayes wrote:
 I did notice the problem with only detecting a LAN failure and was looking at 
 a better monitor.  If I just used plain PF rules what would I use for the 
 next-hop parameter to the route-to command? This IP is dynamic.

There is no next-hop. Just make your rule point to the interface. 
route-to (if). You can also make it route-to if. In either cases, you'd be 
better off using ifstated/relayd with anchors to dynamicaly change your rules, 
in case of link failures. Also, if possible, use snmp to query your 
modems/routers to determine the internet link availability.

Cheers

Route-to with a dynamic 'next hop'

[Justin Mayes]

Greetings all -

I have 2 internet connections. One of them is static IP, one is dynamic. I
want to use both of them on my gateway. From the man pages and other docs I
see the use of route-to in the pf.conf including the 'next-hop' that it
requires. This is easy enough. Problem is that the next hop is hard coded IP
in all examples. I need that next hop to get updated when my one WAN DHCP link
is updated. I know about if:peer, if:broadcast, if:network ect but there is no
if:gateway. Seems like you could have used dhclient-script to adjust pf config
when ip changed but dhclient-script has been removed.  I also read that relayd
has become the best option to accomplish this uplink load balancing in current
versions of OpenBSD. I wanted to check with you all to make sure I'm not
missing something basic with the load balanced uplink scenario in OpenBSD. As
always, comments and suggestions are much appreciated.

J

Re: Route-to with a dynamic 'next hop'

[Justin Mayes]

I just watched Reyk's youtube. I'm going with relayd. I can see the 'routers' 
section in the man page for relayd to do what I want. 

http://www.youtube.com/watch?v=JtMxGslqGbM


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
Justin Mayes
Sent: Wednesday, October 8, 2014 10:04 PM
To: misc@openbsd.org
Subject: Route-to with a dynamic 'next hop'

Greetings all -

I have 2 internet connections. One of them is static IP, one is dynamic. I want 
to use both of them on my gateway. From the man pages and other docs I see the 
use of route-to in the pf.conf including the 'next-hop' that it requires. This 
is easy enough. Problem is that the next hop is hard coded IP in all examples. 
I need that next hop to get updated when my one WAN DHCP link is updated. I 
know about if:peer, if:broadcast, if:network ect but there is no if:gateway. 
Seems like you could have used dhclient-script to adjust pf config when ip 
changed but dhclient-script has been removed.  I also read that relayd has 
become the best option to accomplish this uplink load balancing in current 
versions of OpenBSD. I wanted to check with you all to make sure I'm not 
missing something basic with the load balanced uplink scenario in OpenBSD. As 
always, comments and suggestions are much appreciated.

J

Re: snort inline

[Justin Mayes]

So snort was running and I could use my little C test divert program also to
see I was passing packets back and forth thru divert. I never got a snort
alert though even though traffic was passing to and from client. So after
noticing the snort exit output that showed bad chk sum: 100.000% I used
the snort -k none option and now snort is alerting also. Just an FYI in case
this is at all related to your work. I have run snort a lot in the past but
never on OpenBSD so I don't know if that's normal or not.

Justin 


-Original Message-
From: Justin Mayes 
Sent: Thursday, March 07, 2013 4:02 PM
To: 'Lawrence Teo'
Cc: misc@openbsd.org
Subject: RE: snort inline

This works. Thank you very much. I'll let you know if I run into any issues
but I am able to run snort inline now along with NAT.

Justin 


-Original Message-
From: Lawrence Teo [mailto:l...@openbsd.org] 
Sent: Wednesday, March 06, 2013 8:55 AM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: snort inline

Hi Justin,

Not sure if you still need to use divert-packet with NAT, but if you do,
could you please try the diff at
http://marc.info/?l=openbsd-techm=136245826921904w=2 to see if it works
for you?

The easiest way to get the diff is:

ftp -o divert-checksum.diff \
'http://marc.info/?l=openbsd-techm=136245826921904q=raw'

If you do try it, please let me know if it works for you.

Thanks,
Lawrence

On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote:
 Another update in case there is any interest in running divert-packet 
 along with NATing. I ditched snort and wrote a little divert program 
 based on the man page to test easier. I can now see that with nat as 
 well as divert-packet on egress rule on external interface the packet 
 will get NATed and go out. A reply will come back to external 
 interface and then get diverted again and never make it to the client. 
 I am as sure as I can be at this point that you cannot divert packets from
a NATed client.
 
 Justin
 
 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin
 Sent: Sunday, November 25, 2012 4:37 PM
 To: misc@openbsd.org
 Subject: Re: snort inline
 
 Quick update. It seems to be a nat problem. If I just test by pinging 
 either the 192.168.1.32 interface or the 192.168.0.13 interface it 
 works fine and snort sees the packets. Its only when the traffic is NATed
that it fails.
 
 
 
 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin
 Sent: Saturday, November 24, 2012 2:21 PM
 To: misc@openbsd.org
 Subject: snort inline
 
 Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? 
 From what I read it's possible with pf divert functionality.
 
 This is what I'm doing for testing in pf using simple ping
 
  
 
 Gateway info
 
 internal interface fxp0 - 192.168.1.32
 
 external interface bce0 - 192.168.0.13
 
  
 
 Running snort via this cmd line
 
 snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c 
 /etc/snort/snort.conf -v
 
  
 
 Internal interface is in the skip list hence no active rules for it
 
 Pfctl -sr
 
 pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)
 
 pass in on bce0 inet all flags S/SA scrub (reassemble tcp)
 
  
 
 This works as expected, I can ping 8.8.8.8 and since no diverting is 
 active snort sees nothing
 
 I change rules to this to start diverting to snort
 
 Pfctl -sr
 
 pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet 
 port
 8000 nat-to (bce0:0)
 
 pass in on bce0 inet all flags S/SA scrub (reassemble tcp)
 
  
 
 Now internal interface sees outgoing ping
 
 tcpdump -n -i fxp0 -n host 8.8.8.8
 
 192.168.1.32  8.8.8.8: icmp: request:
 
  
 
 External interface shows it going out and coming back
 
 192.168.0.13  8.8.8.8: icmp: request:
 
 8.8.8.8  192.168.0.13: icmp: reply:
 
  
 
 Snort sees it twice, external interface first
 
 192.168.0.13 - 8.8.8.8
 
 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
 
 Type:8  Code:0  ID:64870   Seq:2  ECHO
 
 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 =+=+
 
  
 
 8.8.8.8 - 192.168.1.32
 
 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84
 
 Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY
 
 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 =+=+
 
  
 
 Client @ 192.168.1.32 never sees reply. Any comments or suggestions?
 
  
 
 Justin

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: snort inline

[Justin Mayes]

FYI 

This patch has corrected my issues with snort inline and NAT

http://marc.info/?l=openbsd-techm=136245826921904w=2





-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Wednesday, December 19, 2012 3:10 PM
To: misc@openbsd.org
Subject: Re: snort inline

Another update in case there is any interest in running divert-packet along
with NATing. I ditched snort and wrote a little divert program based on the
man page to test easier. I can now see that with nat as well as
divert-packet on egress rule on external interface the packet will get NATed
and go out. A reply will come back to external interface and then get
diverted again and never make it to the client. I am as sure as I can be at
this point that you cannot divert packets from a NATed client.

Justin

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin
Sent: Sunday, November 25, 2012 4:37 PM
To: misc@openbsd.org
Subject: Re: snort inline

Quick update. It seems to be a nat problem. If I just test by pinging either
the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and
snort sees the packets. Its only when the traffic is NATed that it fails. 



-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin
Sent: Saturday, November 24, 2012 2:21 PM
To: misc@openbsd.org
Subject: snort inline

Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From
what I read it's possible with pf divert functionality. 

This is what I'm doing for testing in pf using simple ping

 

Gateway info 

internal interface fxp0 - 192.168.1.32

external interface bce0 - 192.168.0.13

 

Running snort via this cmd line

snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v

 

Internal interface is in the skip list hence no active rules for it

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

This works as expected, I can ping 8.8.8.8 and since no diverting is active
snort sees nothing

I change rules to this to start diverting to snort

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port
8000 nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

Now internal interface sees outgoing ping

tcpdump -n -i fxp0 -n host 8.8.8.8

192.168.1.32  8.8.8.8: icmp: request:

 

External interface shows it going out and coming back

192.168.0.13  8.8.8.8: icmp: request:

8.8.8.8  192.168.0.13: icmp: reply:

 

Snort sees it twice, external interface first

192.168.0.13 - 8.8.8.8

ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF

Type:8  Code:0  ID:64870   Seq:2  ECHO

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

8.8.8.8 - 192.168.1.32

ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84

Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Client @ 192.168.1.32 never sees reply. Any comments or suggestions?

 

Justin 

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: snort inline

[Justin Mayes]

This works. Thank you very much. I'll let you know if I run into any issues
but I am able to run snort inline now along with NAT.

Justin 


-Original Message-
From: Lawrence Teo [mailto:l...@openbsd.org] 
Sent: Wednesday, March 06, 2013 8:55 AM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: snort inline

Hi Justin,

Not sure if you still need to use divert-packet with NAT, but if you do,
could you please try the diff at
http://marc.info/?l=openbsd-techm=136245826921904w=2 to see if it works
for you?

The easiest way to get the diff is:

ftp -o divert-checksum.diff \
'http://marc.info/?l=openbsd-techm=136245826921904q=raw'

If you do try it, please let me know if it works for you.

Thanks,
Lawrence

On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote:
 Another update in case there is any interest in running divert-packet 
 along with NATing. I ditched snort and wrote a little divert program 
 based on the man page to test easier. I can now see that with nat as 
 well as divert-packet on egress rule on external interface the packet 
 will get NATed and go out. A reply will come back to external 
 interface and then get diverted again and never make it to the client. 
 I am as sure as I can be at this point that you cannot divert packets from
a NATed client.
 
 Justin
 
 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin
 Sent: Sunday, November 25, 2012 4:37 PM
 To: misc@openbsd.org
 Subject: Re: snort inline
 
 Quick update. It seems to be a nat problem. If I just test by pinging 
 either the 192.168.1.32 interface or the 192.168.0.13 interface it 
 works fine and snort sees the packets. Its only when the traffic is NATed
that it fails.
 
 
 
 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf 
 Of Justin
 Sent: Saturday, November 24, 2012 2:21 PM
 To: misc@openbsd.org
 Subject: snort inline
 
 Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? 
 From what I read it's possible with pf divert functionality.
 
 This is what I'm doing for testing in pf using simple ping
 
  
 
 Gateway info
 
 internal interface fxp0 - 192.168.1.32
 
 external interface bce0 - 192.168.0.13
 
  
 
 Running snort via this cmd line
 
 snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c 
 /etc/snort/snort.conf -v
 
  
 
 Internal interface is in the skip list hence no active rules for it
 
 Pfctl -sr
 
 pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)
 
 pass in on bce0 inet all flags S/SA scrub (reassemble tcp)
 
  
 
 This works as expected, I can ping 8.8.8.8 and since no diverting is 
 active snort sees nothing
 
 I change rules to this to start diverting to snort
 
 Pfctl -sr
 
 pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet 
 port
 8000 nat-to (bce0:0)
 
 pass in on bce0 inet all flags S/SA scrub (reassemble tcp)
 
  
 
 Now internal interface sees outgoing ping
 
 tcpdump -n -i fxp0 -n host 8.8.8.8
 
 192.168.1.32  8.8.8.8: icmp: request:
 
  
 
 External interface shows it going out and coming back
 
 192.168.0.13  8.8.8.8: icmp: request:
 
 8.8.8.8  192.168.0.13: icmp: reply:
 
  
 
 Snort sees it twice, external interface first
 
 192.168.0.13 - 8.8.8.8
 
 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF
 
 Type:8  Code:0  ID:64870   Seq:2  ECHO
 
 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 =+=+
 
  
 
 8.8.8.8 - 192.168.1.32
 
 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84
 
 Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY
 
 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 =+=+
 
  
 
 Client @ 192.168.1.32 never sees reply. Any comments or suggestions?
 
  
 
 Justin

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Kernel Debugging

[Justin Mayes]

Absolutely. Nothing custom, the build errors have all been fixed at least in
CURRENT so I just had to get the kernel config right. 

Ddb and kgdb are mutually exclusive so your kernel must be built for one or
the other.

For ddb
It's there by default in GENERIC, you just have to set sysctl
machdep.kbdreset to 2 and reboot so you can break in with ctrl-alt-delete,
see man ddb page.

If you want to be able to parse structs easier add this to
/usr/src/sys/conf/GENERIC and build new kernel

Option  DDB_STRUCT



For kgdb
Uncomment these options in /usr/src/sys/arch/i386/conf/GENERIC or make a
different copy

Option  KGDB
Option  KGDB_DEVNAME=\com\,KGDBADDR=0x2f8,KGDBRATE=9600


Pay attention to the 0x2f8 there, you may need 0x3f8 to listen on com0
rather than com1

Run Dmesg | grep com to see

Then in file /usr/src/sys/conf/GENERIC (or your debug copy) comment out the
DDB stuff

#option DDB
#option DDB_SAFE_CONSOLE

Uncomment 

Makeoptions DEBUG=-g


Then build your kernel

Comments and corrections are welcome. 

Justin 


-Original Message-
From: sickm...@lavabit.com [mailto:sickm...@lavabit.com] 
Sent: Tuesday, January 08, 2013 6:44 AM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

On 17:04 Mon 07 Jan , Justin Mayes wrote:
 I got this. I had 2 com ports on this old target desktop and when I 
 switched the serial cable to the right one, it worked. I have working 
 DDB kernel with structs as well as a working kgdb kernel with current.
 
 Justin

Good. Any chance to get patches and kernel config from you?

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Kernel Debugging

[Justin Mayes]

So now that I got ddb working good I went back and built kernel with KGDB
options per the 'man KGDB' page. I followed the other steps and I have a
null modem cable hooked up. When I run 'gdb bsd.gdb' on the control system
and then 'target remote /dev/cua00', it does not break into debugger on the
target system. Now that current kernel builds with KGDB option, is anyone
using it?

Justin 


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Monday, December 24, 2012 11:07 AM
To: Philip Guenther
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

Your right. I can view that struct also. The other structs I tried must have
been out of scope. Thanks for your help Philip.

J



-Original Message-
From: Philip Guenther [mailto:guent...@gmail.com]
Sent: Sunday, December 23, 2012 6:51 PM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

On Sun, Dec 23, 2012 at 1:34 PM, Justin Mayes jma...@careered.com wrote:
 I was looking into kernel debug options and found that trying to build 
 a kernel with kgdb option enabled fails.

If no one uses it, it won't keep working.  Submitting a patch to fix the
build would be a first step.  I suggest trying it both with DDB and without
DDB: those should both work.


 Anyone using the kgdb setup? I can
 use ddb it's just painful to have to manually walk structures to 
 examine values. I have moved on to plan B which was to build with 
 option  DDB_STRUCT and the build is a success but the 'show struct'
 command always returns 'unknown structure' for anything other than 
 mbuf. Anyone have any kernel debugging strategies they'd like to share?

DDB_STRUCT works for me for other structures.  For example, here's a session
looking at a firefox struct proc:

Stopped at  Debugger+0x5:   leave
 ddb{0} ps/a
 PID  COMMAND  STRUCT PROC * UAREA *  VMSPACE/VM_MAP
 16253  firefox 0xfe812af09798  0x800032dd6000
0xfe81305ec1d0
  8061  xpdf0xfe81280e1a08  0x800032dfe000
0xfe81305ecd30
 31009  firefox 0xfe81280e17a0  0x800032df9000
0xfe81305ec1d0
  5390  firefox 0xfe81280e1c70  0x800032e0d000
0xfe81305ec1d0
 10871  less0xfe81280e1068  0x800032df4000
0xfe81305ece10
 28672  vi  0xfe8129b0d7a8  0x800032e16000
0xfe81305ecb70
 24081  firefox 0xfe81280e12d0  0x800032def000
0xfe81305ec1d0
 29697  firefox 0xfe812af09c68  0x800032de5000
0xfe81305ec1d0
 19401  firefox 0xfe812af09a00  0x800032de
0xfe81305ec1d0
 27330  firefox 0xfe8135a2b4f0  0x800032ddb000
0xfe81305ec1d0
 13735  firefox 0xfe812af09530  0x800032dd1000
0xfe81305ec1d0
   819  firefox 0xfe812af092c8  0x800032dcc000
0xfe81305ec1d0
 13812  firefox 0xfe812de71c60  0x800032dc2000
0xfe81305ec1d0
 15769  firefox 0xfe812af09060  0x800032dc7000
0xfe81305ec1d0
  2108  firefox 0xfe812de719f8  0x800032dbd000
0xfe81305ec1d0
  7957  firefox 0xfe812de71790  0x800032db8000
0xfe81305ec1d0
 20128  firefox 0xfe812de71528  0x800032db3000
0xfe81305ec1d0
  4339  firefox 0xfe812de712c0  0x800032da6000
0xfe81305ec1d0
 20161  firefox 0xfe812de71058  0x800032da1000
0xfe81305ec1d0
  4258  firefox 0xfe812f591c58  0x800032d9c000
0xfe81305ec1d0
  4495  firefox 0xfe812f5919f0  0x800032d8f000
0xfe81305ec1d0
 ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd   8 fe81377d1898
p_vmspace  8 fe81305ec1d0
p_sigacts  8 fe8136f246c0
p_exitsig  40
p_flag 4  4100080
p_spare1   ef
p_stat 13
p_pad1 1   af
p_descfd   1   de
p_pid  4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait  40
p_estcpu   40
p_cpticks  40
p_pctcpu   40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime   4   32
p_slptime  4e
p_cpu  8

Re: Kernel Debugging

[Justin Mayes]

I got this. I had 2 com ports on this old target desktop and when I switched
the serial cable to the right one, it worked. I have working DDB kernel with
structs as well as a working kgdb kernel with current. 

Justin


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Monday, January 07, 2013 2:35 PM
To: misc@openbsd.org
Subject: Re: Kernel Debugging

So now that I got ddb working good I went back and built kernel with KGDB
options per the 'man KGDB' page. I followed the other steps and I have a
null modem cable hooked up. When I run 'gdb bsd.gdb' on the control system
and then 'target remote /dev/cua00', it does not break into debugger on the
target system. Now that current kernel builds with KGDB option, is anyone
using it?

Justin 


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Monday, December 24, 2012 11:07 AM
To: Philip Guenther
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

Your right. I can view that struct also. The other structs I tried must have
been out of scope. Thanks for your help Philip.

J



-Original Message-
From: Philip Guenther [mailto:guent...@gmail.com]
Sent: Sunday, December 23, 2012 6:51 PM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

On Sun, Dec 23, 2012 at 1:34 PM, Justin Mayes jma...@careered.com wrote:
 I was looking into kernel debug options and found that trying to build 
 a kernel with kgdb option enabled fails.

If no one uses it, it won't keep working.  Submitting a patch to fix the
build would be a first step.  I suggest trying it both with DDB and without
DDB: those should both work.


 Anyone using the kgdb setup? I can
 use ddb it's just painful to have to manually walk structures to 
 examine values. I have moved on to plan B which was to build with 
 option  DDB_STRUCT and the build is a success but the 'show struct'
 command always returns 'unknown structure' for anything other than 
 mbuf. Anyone have any kernel debugging strategies they'd like to share?

DDB_STRUCT works for me for other structures.  For example, here's a session
looking at a firefox struct proc:

Stopped at  Debugger+0x5:   leave
 ddb{0} ps/a
 PID  COMMAND  STRUCT PROC * UAREA *  VMSPACE/VM_MAP
 16253  firefox 0xfe812af09798  0x800032dd6000
0xfe81305ec1d0
  8061  xpdf0xfe81280e1a08  0x800032dfe000
0xfe81305ecd30
 31009  firefox 0xfe81280e17a0  0x800032df9000
0xfe81305ec1d0
  5390  firefox 0xfe81280e1c70  0x800032e0d000
0xfe81305ec1d0
 10871  less0xfe81280e1068  0x800032df4000
0xfe81305ece10
 28672  vi  0xfe8129b0d7a8  0x800032e16000
0xfe81305ecb70
 24081  firefox 0xfe81280e12d0  0x800032def000
0xfe81305ec1d0
 29697  firefox 0xfe812af09c68  0x800032de5000
0xfe81305ec1d0
 19401  firefox 0xfe812af09a00  0x800032de
0xfe81305ec1d0
 27330  firefox 0xfe8135a2b4f0  0x800032ddb000
0xfe81305ec1d0
 13735  firefox 0xfe812af09530  0x800032dd1000
0xfe81305ec1d0
   819  firefox 0xfe812af092c8  0x800032dcc000
0xfe81305ec1d0
 13812  firefox 0xfe812de71c60  0x800032dc2000
0xfe81305ec1d0
 15769  firefox 0xfe812af09060  0x800032dc7000
0xfe81305ec1d0
  2108  firefox 0xfe812de719f8  0x800032dbd000
0xfe81305ec1d0
  7957  firefox 0xfe812de71790  0x800032db8000
0xfe81305ec1d0
 20128  firefox 0xfe812de71528  0x800032db3000
0xfe81305ec1d0
  4339  firefox 0xfe812de712c0  0x800032da6000
0xfe81305ec1d0
 20161  firefox 0xfe812de71058  0x800032da1000
0xfe81305ec1d0
  4258  firefox 0xfe812f591c58  0x800032d9c000
0xfe81305ec1d0
  4495  firefox 0xfe812f5919f0  0x800032d8f000
0xfe81305ec1d0
 ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd   8 fe81377d1898
p_vmspace  8 fe81305ec1d0
p_sigacts  8 fe8136f246c0
p_exitsig  40
p_flag 4  4100080
p_spare1   ef
p_stat 13
p_pad1 1   af
p_descfd   1   de
p_pid  4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait  40
p_estcpu

Re: Kernel Debugging

[Justin Mayes]

Your right. I can view that struct also. The other structs I tried must have
been out of scope. Thanks for your help Philip.

J



-Original Message-
From: Philip Guenther [mailto:guent...@gmail.com] 
Sent: Sunday, December 23, 2012 6:51 PM
To: Justin Mayes
Cc: misc@openbsd.org
Subject: Re: Kernel Debugging

On Sun, Dec 23, 2012 at 1:34 PM, Justin Mayes jma...@careered.com wrote:
 I was looking into kernel debug options and found that trying to build 
 a kernel with kgdb option enabled fails.

If no one uses it, it won't keep working.  Submitting a patch to fix the
build would be a first step.  I suggest trying it both with DDB and without
DDB: those should both work.


 Anyone using the kgdb setup? I can
 use ddb it's just painful to have to manually walk structures to 
 examine values. I have moved on to plan B which was to build with 
 option  DDB_STRUCT and the build is a success but the 'show struct' 
 command always returns 'unknown structure' for anything other than 
 mbuf. Anyone have any kernel debugging strategies they'd like to share?

DDB_STRUCT works for me for other structures.  For example, here's a session
looking at a firefox struct proc:

Stopped at  Debugger+0x5:   leave
 ddb{0} ps/a
 PID  COMMAND  STRUCT PROC * UAREA *  VMSPACE/VM_MAP
 16253  firefox 0xfe812af09798  0x800032dd6000
0xfe81305ec1d0
  8061  xpdf0xfe81280e1a08  0x800032dfe000
0xfe81305ecd30
 31009  firefox 0xfe81280e17a0  0x800032df9000
0xfe81305ec1d0
  5390  firefox 0xfe81280e1c70  0x800032e0d000
0xfe81305ec1d0
 10871  less0xfe81280e1068  0x800032df4000
0xfe81305ece10
 28672  vi  0xfe8129b0d7a8  0x800032e16000
0xfe81305ecb70
 24081  firefox 0xfe81280e12d0  0x800032def000
0xfe81305ec1d0
 29697  firefox 0xfe812af09c68  0x800032de5000
0xfe81305ec1d0
 19401  firefox 0xfe812af09a00  0x800032de
0xfe81305ec1d0
 27330  firefox 0xfe8135a2b4f0  0x800032ddb000
0xfe81305ec1d0
 13735  firefox 0xfe812af09530  0x800032dd1000
0xfe81305ec1d0
   819  firefox 0xfe812af092c8  0x800032dcc000
0xfe81305ec1d0
 13812  firefox 0xfe812de71c60  0x800032dc2000
0xfe81305ec1d0
 15769  firefox 0xfe812af09060  0x800032dc7000
0xfe81305ec1d0
  2108  firefox 0xfe812de719f8  0x800032dbd000
0xfe81305ec1d0
  7957  firefox 0xfe812de71790  0x800032db8000
0xfe81305ec1d0
 20128  firefox 0xfe812de71528  0x800032db3000
0xfe81305ec1d0
  4339  firefox 0xfe812de712c0  0x800032da6000
0xfe81305ec1d0
 20161  firefox 0xfe812de71058  0x800032da1000
0xfe81305ec1d0
  4258  firefox 0xfe812f591c58  0x800032d9c000
0xfe81305ec1d0
  4495  firefox 0xfe812f5919f0  0x800032d8f000
0xfe81305ec1d0
 ddb{0} show struct
proc 0xfe812af09798
struct proc at 0xfe812af09798 (616 bytes)
p_runq 16
p_list 16
p_p8 fe81368ad7c8
p_thr_link 16
p_fd   8 fe81377d1898
p_vmspace  8 fe81305ec1d0
p_sigacts  8 fe8136f246c0
p_exitsig  40
p_flag 4  4100080
p_spare1   ef
p_stat 13
p_pad1 1   af
p_descfd   1   de
p_pid  4 3f7d
p_hash 16
p_dupfd40
p_thrslpid 82309e1800
p_sigwait  40
p_estcpu   40
p_cpticks  40
p_pctcpu   40
p_wchan8 fe812af09810
p_sleep_to 40
p_wmesg8 8083585c
p_swtime   4   32
p_slptime  4e
p_cpu  8 801c1000
p_ru   144
p_tu   40
p_rtime16
p_uticks   40
p_sticks   40
p_iticks   40
p_systrace 80
p_siglist  40
p_textvp   8 fe812e522160
p_emuldata 80
p_sigdivert40
p_sigmask  40
p_priority

Kernel Debugging

[Justin Mayes]

I was looking into kernel debug options and found that trying to build a
kernel with kgdb option enabled fails. Anyone using the kgdb setup? I can
use ddb it's just painful to have to manually walk structures to examine
values. I have moved on to plan B which was to build with option  DDB_STRUCT
and the build is a success but the 'show struct' command always returns
'unknown structure' for anything other than mbuf. Anyone have any kernel
debugging strategies they'd like to share?

 

Justin

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: snort inline

[Justin Mayes]

Another update in case there is any interest in running divert-packet along
with NATing. I ditched snort and wrote a little divert program based on the
man page to test easier. I can now see that with nat as well as
divert-packet on egress rule on external interface the packet will get
NATed and go out. A reply will come back to external interface and then get
diverted again and never make it to the client. I am as sure as I can be at
this point that you cannot divert packets from a NATed client.

Justin

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin 
Sent: Sunday, November 25, 2012 4:37 PM
To: misc@openbsd.org
Subject: Re: snort inline

Quick update. It seems to be a nat problem. If I just test by pinging either
the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and
snort sees the packets. Its only when the traffic is NATed that it fails. 



-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin 
Sent: Saturday, November 24, 2012 2:21 PM
To: misc@openbsd.org
Subject: snort inline

Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From
what I read it's possible with pf divert functionality. 

This is what I'm doing for testing in pf using simple ping

 

Gateway info 

internal interface fxp0 - 192.168.1.32

external interface bce0 - 192.168.0.13

 

Running snort via this cmd line

snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v

 

Internal interface is in the skip list hence no active rules for it

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

This works as expected, I can ping 8.8.8.8 and since no diverting is active
snort sees nothing

I change rules to this to start diverting to snort

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port
8000 nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

Now internal interface sees outgoing ping

tcpdump -n -i fxp0 -n host 8.8.8.8

192.168.1.32  8.8.8.8: icmp: request:

 

External interface shows it going out and coming back

192.168.0.13  8.8.8.8: icmp: request:

8.8.8.8  192.168.0.13: icmp: reply:

 

Snort sees it twice, external interface first

192.168.0.13 - 8.8.8.8

ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF

Type:8  Code:0  ID:64870   Seq:2  ECHO

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

8.8.8.8 - 192.168.1.32

ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84

Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Client @ 192.168.1.32 never sees reply. Any comments or suggestions?

 

Justin 

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Recommended ANSI C language coding standard compliance checker

[Justin Mayes]

I read someone mention 'man style' the other day and I'm glad I did. It's
not a standard of any kind but it helped me understand OpenBSD source
better. Seems like a lot of it conforms to most of these rules if not all.


Justin Mayes 
Infrastructure Solution Architect 
Career Education Corporation
Office: 847.783.8150 x38150 | jma...@careered.com

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Gleydson Soares
Sent: Tuesday, November 27, 2012 8:54 PM
To: Philip Guenther
Cc: Tito Mari Francis Escaño; misc@openbsd.org
Subject: Re: Recommended ANSI C language coding standard compliance checker

+1.

On Wed, Nov 28, 2012 at 12:46 AM, Philip Guenther guent...@gmail.com
wrote:
 On Mon, Nov 26, 2012 at 8:10 PM, Tito Mari Francis Escaño
 titomarifran...@gmail.com wrote:
 I'm trying to re-learn ANSI C as part of the effort to write a book
 for beginners or intermediate level. I'm thinking of including the
 use of ANSI C code compliance checker, similar to PHP CodeSniffer,
 that detects whether a given C program file complies with a coding
 standard. Can you please give me pointers what tools OpenBSD
 developers use for this purpose? I understand that indent is used to
 format a given program file, but how about detecting whether a given file
is coding standard compliant?

 The only tool *this* OpenBSD developer uses for checking *coding
 standard* compliance is his brain.  For KNF stuff (c.f. style(9)) you
 just read enough of it and the stuff that's wrong starts to stick out.
  But really, that's just the bottom level: syntax is important only
 because it can obscure the semantics.  It's like when reading a book:
 the font it was printed in doesn't matter unless it distracts you from
 the *words*.

 What's important in coding style are things like clarity, portability,
 and efficiency.  While a few aspects of portability can be checked
 mechanically, those mostly have to be checked *and balanced* by a
 brain.


 I recommend the book The Practice of Programming, by Brian W.
 Kernighan and Rob Pike, for those interested in these sorts of
 considerations.


 Philip Guenther

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: snort inline

[Justin Mayes]

Quick update. It seems to be a nat problem. If I just test by pinging either
the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and
snort sees the packets. Its only when the traffic is NATed that it fails. 



-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Justin Mayes
Sent: Saturday, November 24, 2012 2:21 PM
To: misc@openbsd.org
Subject: snort inline

Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From
what I read it's possible with pf divert functionality. 

This is what I'm doing for testing in pf using simple ping

 

Gateway info 

internal interface fxp0 - 192.168.1.32

external interface bce0 - 192.168.0.13

 

Running snort via this cmd line

snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v

 

Internal interface is in the skip list hence no active rules for it

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

This works as expected, I can ping 8.8.8.8 and since no diverting is active
snort sees nothing

I change rules to this to start diverting to snort

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port
8000 nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

Now internal interface sees outgoing ping

tcpdump -n -i fxp0 -n host 8.8.8.8

192.168.1.32  8.8.8.8: icmp: request:

 

External interface shows it going out and coming back

192.168.0.13  8.8.8.8: icmp: request:

8.8.8.8  192.168.0.13: icmp: reply:

 

Snort sees it twice, external interface first

192.168.0.13 - 8.8.8.8

ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF

Type:8  Code:0  ID:64870   Seq:2  ECHO

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

8.8.8.8 - 192.168.1.32

ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84

Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Client @ 192.168.1.32 never sees reply. Any comments or suggestions?

 

Justin Mayes 

[demime 1.01d removed an attachment of type application/pkcs7-signature
which had a name of smime.p7s]

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

snort inline

[Justin Mayes]

Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From
what I read it's possible with pf divert functionality. 

This is what I'm doing for testing in pf using simple ping

 

Gateway info 

internal interface fxp0 - 192.168.1.32

external interface bce0 - 192.168.0.13

 

Running snort via this cmd line

snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf
-v

 

Internal interface is in the skip list hence no active rules for it

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

This works as expected, I can ping 8.8.8.8 and since no diverting is active
snort sees nothing

I change rules to this to start diverting to snort

Pfctl -sr

pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port
8000 nat-to (bce0:0)

pass in on bce0 inet all flags S/SA scrub (reassemble tcp)

 

Now internal interface sees outgoing ping

tcpdump -n -i fxp0 -n host 8.8.8.8

192.168.1.32  8.8.8.8: icmp: request:

 

External interface shows it going out and coming back

192.168.0.13  8.8.8.8: icmp: request:

8.8.8.8  192.168.0.13: icmp: reply:

 

Snort sees it twice, external interface first

192.168.0.13 - 8.8.8.8

ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF

Type:8  Code:0  ID:64870   Seq:2  ECHO

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

8.8.8.8 - 192.168.1.32

ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84

Type:0  Code:0  ID:52297  Seq:2  ECHO REPLY

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

 

Client @ 192.168.1.32 never sees reply. Any comments or suggestions?

 

Justin Mayes 

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Hardware hunting

[Justin Mayes]

Check out http://soekris.com/. I have a low end one and it works great.
Little costly though.

Justin Mayes 


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Chris McGee
Sent: Thursday, November 15, 2012 3:48 PM
To: misc@openbsd.org
Subject: Hardware hunting

Hi guys-

  I am hunting for a low-power firewall for my home network. For at least
10 years, whenever my firewall hardware has started to die, I've grabbed a
decommissioned game PC, added a few NIC's, and put OpenBSD on it.  The
firewall's current incarnation pulls about 160 watts 24/7; I'd like to lower
that by a lot.

  Requirements are:
   1) Low power (50w; I want it to pay for itself before the hardware dies)
   2) 4 network interfaces (3 gigabit, one gigabit or 100mbps)
   3) Cheaper is better (e.g., a $200 4-port PCIE NIC on a $75 motherboard
is suboptimal)
   4) Works with OpenBSD 5.2
   5) Won't cause a hardware bottleneck when pushing 200mbps of
multidirectional traffic through a moderately complex pf ruleset (this
doesn't take a lot of CPU; a 1 GHz Athlon runs at about 2% under load, and
most of that is from hardware interrupts).

  It looks like a lot of people use the Alix 2D13 for this, but I rejected
it for poor throughput (it would be great for the internet connection, but
it sounds like it might be a serious bottleneck between the internal
networks).

  Jetway makes a number of promising-looking Atom boards, including the
4-interface NF38, but the NF38 and many other JetWays use the Realtek
RTL8111EVL, which doesn't appear to be OpenBSD-friendly. You can add
interfaces to Jetway boards via their daughterboards, but those are either
Realtek RTL8111F or Intel 82574L; same problem.  (Google turns up one report
of the RTL8111 series sorta working with -current, but if you read the guy's
dmesg, it doesn't look like he HAS an RTL8111 in the first place.)


  ...anyway, if you have a low-power OpenBSD network appliance with 3-4
interfaces that you're happy with, please give me a yell. I've been through
a lot of boards without finding a winner so far!

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: Unified BSD?

[Justin Mayes]

Yes, your bat crap crazy :-)

All of these variants inherit from the same unified BSD 4.4 base code as far
as I know. So years ago  there were reasons that groups wanted to spilt off
and focus on specific goals. Some of these goals are mutually exclusive.
These BSD variants are not really competing with each other or Linux for
that matter.


Justin Mayes 


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Robin Björklin
Sent: Monday, November 12, 2012 2:38 PM
To: us...@dragonflybsd.org; netbsd-us...@netbsd.org;
freebsd-c...@freebsd.org; misc@openbsd.org
Subject: Unified BSD?

Hi!

First and foremost I'd like to present myself, I'm a young and naive junior
sys admin that think people should be able to compromise and see the bigger
picture and the good of the cause.

Now over to the reason for my post.

As all of you probably know there's a lot of buzz around Gnu/Linux these
days and I'm pretty sure you couldn't care less. What I'm wondering is why
the BSD community which from what I can gather isn't as big as the Linux
community have decided to split their resources into several different
projects/forks/distributions. To me it seems *BSD would be in a more
competitive shape if all developers would get in under one roof?

Am I bat crap crazy for thinking it could be good to merge the four largest
BSD variants out there, take the best bits and pieces out of each and create
a Unified BSD?

Kind Regards,
Robin Bjorklin

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]