Re: IPsec and MTU / fragmentation

[Simen Stavdal]

If a client and a server set up a new conversation over tcp.
They both have an MTU of 1500 and DF=1
How will you fragment this, even being a L3 tunnel?

/S

On Tue, 11 Feb 2020 at 08:22, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 20:53 skrev Simen Stavdal :
>
>> I think the more complete solution is to run some gif/gre inside ipsec
>>> and set low-enough MTU on that one, so it can correctly fragment incoming
>>> packets, and optionally rebuild the packets at the remote end, while also
>>> giving you an idea of "state" on the link so you optionally can run things
>>> like routing daemons or something that cares about and acts on tunnel
>>> state. This would cause even lower MTU, but still allow all kinds of
>>> traffic and not just the "popular" one.
>>>
>>
>> So, how will your client/server know about this lower mtu? And df bit is
>> set more often than not, so fragmentation is now allowed in a lot of cases.
>> This is exactly the problem that started this thread...
>>
>>>
>>>
> If the inner gif/gre tunnel has a lower mtu, then it being a layer-3
> tunnel will be able to fragment all incoming ip before sending it into the
> ipsec, which will not fragment for you.
> The clients will not have to change, nor any other protocol that sends ip
> via the double-tunnel.
>
> --
> May the most significant bit of your life be positive.
>

Re: IPsec and MTU / fragmentation

[Simen Stavdal]

On Mon, 10 Feb 2020 at 17:00, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 16:27 skrev Simen Stavdal :
>
>> This is more a discussion about scalability and practical implementation.
>> We both know that PMTU will work partly at best, your entire path back
>> must support this, and also, the "offending" client must allow inbound
>> control messages on their host firewall for this to work.
>> And even if the packets are received by the client, will it support and
>> adjust MSS? I have seen a lot of clients not adhering to standards.
>>
>> Modifying thousands of clients (via dhcp options for instance) to use a
>> fixed MTU will affect other applications too (if you choose to go that
>> route), not just the ones that need to traverse a tight ipsec tunnel.
>> Would you adjust all your clients just because you had a single path
>> using SLIP in your network?
>>
>
> I would want for noone to ever have to know the complete path, slip or no
> slip.
>
>
>> Point is, there is no perfect solution to this issue, there are just
>> different ways of solving bits and bobs on the way.
>> Adjust mss will work just fine for all tcp protocols, and no, not for UDP
>> because it does not use a three way handshake (no MSS to adjust).
>> In my opinion, max-mss works very well in most cases, especially when you
>> have full control of the tunnel you are using (as is the case of Lucas'
>> original question).
>> We use it extensively in many of our applications in my workplace, and as
>> of yet has not represented any big issues, so it is a practically good way
>> to solve this issue.
>>
>
> I think the more complete solution is to run some gif/gre inside ipsec and
> set low-enough MTU on that one, so it can correctly fragment incoming
> packets, and optionally rebuild the packets at the remote end, while also
> giving you an idea of "state" on the link so you optionally can run things
> like routing daemons or something that cares about and acts on tunnel
> state. This would cause even lower MTU, but still allow all kinds of
> traffic and not just the "popular" one.
>

So, how will your client/server know about this lower mtu? And df bit is
set more often than not, so fragmentation is now allowed in a lot of cases.
This is exactly the problem that started this thread...

>
> I am somewhat trying to care for the ones that make a site-2-site ipsec
> which may work for the initial setup, and later find out that more than one
> non-tcp kind of traffic doesn't work without understanding why ssh,http
> works but not list-of-things-like
> mosh,wireguard,quic,yet-another-layer-of-ipsec,hosting-udp-game doesn't.
>
so, I agree that it would be nice that all protocols would work, but
ultimately the client/server refusing to use fragmentation is really the
problem, when MTU is too small, and clients insist on big packets.

>
> As for UDP, there are options here too in pf.conf (like no-df), but
>> personally I have not tested this, but it would be fun to try. It says it
>> supports IPv4 (which would include TCP, UDP and ICMP).
>> Would be interesting to find if UDP enforces DF in most cases.
>>
>
> no-df in PF more or less controls if it will silently drop fragments that
> arrive which has DF set. Linux used/uses to send such udp, for much
> enjoyment. "noone else should fragment, but I just did and you as the
> packet checker can't know who did"
>

> --
> May the most significant bit of your life be positive.
>

Re: IPsec and MTU / fragmentation

[Simen Stavdal]

This is more a discussion about scalability and practical implementation.
We both know that PMTU will work partly at best, your entire path back must
support this, and also, the "offending" client must allow inbound control
messages on their host firewall for this to work.
And even if the packets are received by the client, will it support and
adjust MSS? I have seen a lot of clients not adhering to standards.

Modifying thousands of clients (via dhcp options for instance) to use a
fixed MTU will affect other applications too (if you choose to go that
route), not just the ones that need to traverse a tight ipsec tunnel.
Would you adjust all your clients just because you had a single path using
SLIP in your network?

Point is, there is no perfect solution to this issue, there are just
different ways of solving bits and bobs on the way.
Adjust mss will work just fine for all tcp protocols, and no, not for UDP
because it does not use a three way handshake (no MSS to adjust).

In my opinion, max-mss works very well in most cases, especially when you
have full control of the tunnel you are using (as is the case of Lucas'
original question).
We use it extensively in many of our applications in my workplace, and as
of yet has not represented any big issues, so it is a practically good way
to solve this issue.

As for UDP, there are options here too in pf.conf (like no-df), but
personally I have not tested this, but it would be fun to try. It says it
supports IPv4 (which would include TCP, UDP and ICMP).
Would be interesting to find if UDP enforces DF in most cases.

Cheers,
Simon.

On Mon, 10 Feb 2020 at 13:50, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 12:15 skrev Simen Stavdal :
>
>> True, but issue was related to downloading over http, which is over tcp.
>> So, if http is your only concern I would go for this option.
>>
>
> To me, it sounds just a bit like "let this person notice the other errors
> later".
>
>
>> Most clients are configured with an MTU of their physical NIC
>> capabilities, and sometimes even with jumbo support.
>> MTU is a property of the OS in both ends, while MSS is a property of the
>> packets that can be adjusted in-flight.
>>
>>
> MTU is strictly a property of each and every interface in all the hops
> between you and your endpoint and equally strictly is mss a property of
> _tcp_ packets that can be adjusted. If you run another ipsec inside this
> first ipsec tunnel-with-mss-fixed that second one would break, since ESP/AH
> is not tcp and will not do the 3way handshake where PF can fix mss for it.
> Or mosh, wireguard, or http/3 since they run over UDP.
>
> Not trying to nitpick everything, but internet wasn't built on 1500 MTU
> ethernet everywhere, in the old bad days you might go over PPP (576) or
> SLIP (296) links at times and it still worked, so if your setups today
> break if someone in your path limits you to 1476 or so, then we have
> regressed quite a bit since the crap internet days.
>
>
>> So, if you want to fix the MTU, you will have to configure that on the
>> conversation parters and not in pf.
>> So, while we agree on the principals, how do you suggest MTU is changed?
>>
>
> PMTU discovery would be one method, yes. Middle boxes that will not drop
> icmp is part if this of course.
>
>
>> Statically configured on each host? DHCP option?
>>
>
> This depends a bit on where you place your ipsec gw of course, but if you
> can't set it on the tunnel (since ipsec on obsd isn't like openvpn or
> gif/gre) you might need to set it on the interface where you take in the
> traffic, if you can't set it on all clients going via the gw, which is a
> believable scenario.
>
>
>> This might fix the http/ssh issues one might see, because both of those
>>> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
>>> any other non-TCP protocol one might run over that ipsec, so making sure
>>> the traffic is below the MTU should be the end goal, not fixing 90% with
>>> pf.
>>>
>>
>
> --
> May the most significant bit of your life be positive.
>

Re: IPsec and MTU / fragmentation

[Simen Stavdal]

True, but issue was related to downloading over http, which is over tcp.
So, if http is your only concern I would go for this option.

Most clients are configured with an MTU of their physical NIC capabilities,
and sometimes even with jumbo support.
MTU is a property of the OS in both ends, while MSS is a property of the
packets that can be adjusted in-flight.

So, if you want to fix the MTU, you will have to configure that on the
conversation parters and not in pf.
So, while we agree on the principals, how do you suggest MTU is changed?

Statically configured on each host? DHCP option?

Cheers,
Simon.

On Mon, 10 Feb 2020 at 12:06, Janne Johansson  wrote:

> Den mån 10 feb. 2020 kl 11:58 skrev Simen Stavdal :
>
>> Hi Lucas,
>> Have you tried to manipulate the mss during conversation setup?
>> This is done with the max-mss directive in pf.conf.
>> Basically, it takes the three way handshake, and overrides the MSS value
>> in
>> the handshake to something lower than the default.
>>
>
> This might fix the http/ssh issues one might see, because both of those
> run over TCP, but MSS fixups will not correct large UDP or icmp packets, or
> any other non-TCP protocol one might run over that ipsec, so making sure
> the traffic is below the MTU should be the end goal, not fixing 90% with
> pf.
>
> --
> May the most significant bit of your life be positive.
>

Re: IPsec and MTU / fragmentation

[Simen Stavdal]

Hi Lucas,

Have you tried to manipulate the mss during conversation setup?
This is done with the max-mss directive in pf.conf.

Basically, it takes the three way handshake, and overrides the MSS value in
the handshake to something lower than the default.

Client (1500 bytes) -> pf (change to 1300 bytes) -> Server
Server (1500 bytes) -> pf (change to 1300 bytes) -> Client

Now, both the server and the client thinks that the remote conversation
partner is only able to receive 1300 bytes, and will package the data
accordingly.

When a normal conversation is set up, it is becoming more and more common
to set DF=1 (don't fragment = true).
When the router/firewall receives packets that are too big, they become
discarded, but the max-mss should take care of this. I.e, while not
allowing fragmentation, but force smaller packets in the first place.

The three way handshake will usually always come true, because the packets
are very small.

Cheers,
Simon.

On Sun, 9 Feb 2020 at 21:35, Lucas  wrote:

> Hi misc@,
>
> I've set up an IPsec tunnel to for serving my website from my home. The
> tunnel works quite well most of the time, but if I try to deliver big
> files over it, the HTTP client never gets a response. After some
> testing, if I ran in the HTTP server end
>
> perl -e 'print "a" x 1386;' | doas nc -l 10.200.0.80 80
>
> client receives 1386 "a"s, but with any bigger size the client sees no
> response at all.
>
> This smells of MTU / fragmentation issues, but I don't know enough about
> networks to configure it properly. Is this the case? Any recommendations
> on how to configure a sensible value? Any clue sticks? I can bang
> different MTUs until it works, but that solution doesn't seem to scale.
> You can find my iked and pf configs below.
>
> Also would like to understand why it happens, so pointers to docs are
> more than welcome.
>
> Thanks in advance,
> -Lucas
>
> Initiator /etc/iked.conf:
>
> initiator_www = 10.200.0.80
> initiator_peer =192.0.2.1
> responder = 198.51.100.1
>
> ikev2 "www" active proto tcp \
> from $initiator_www port 80 to $responder \
> peer $responder \
> srcid initiator dstid responder \
> tag IPSECWWW
>
> Initiator /etc/pf.conf:
>
> set block-policy drop
> set loginterface egress
> set skip on lo0
>
> block all
>
> pass out quick on { egress enc0 }
>
> pass in quick on enc0 tagged IPSECWWW
> pass in on egress proto tcp to port ssh
> pass in on egress inet proto icmp all
> pass in on egress inet6 proto ipv6-icmp all
>
> Responder /etc/iked.conf:
>
> initiator_www = 10.200.0.80
> initiator_peer =192.0.2.1
> responder = 198.51.100.1
>
> ikev2 "www" passive proto tcp \
> from $responder to $initiator_www port 80 \
> peer $initiator_peer \
> srcid responder dstid initiator \
> tag IPSECWWW
>
> Responder /etc/pf.conf:
>
> set block-policy drop
> set loginterface egress
> set skip on lo0
>
> block log all
>
> pass out quick on egress
>
> pass in log on egress proto udp from any to (egress) \
> port { isakmp ipsec-nat-t }
> pass in log on egress proto esp from any to (egress)
> pass in log on enc0 tagged IPSECWWW
> pass out log on enc0
>
> pass in on egress proto tcp to port { ssh http https }
> pass in on egress inet proto icmp all
> pass in on egress inet6 proto icmp6 all
>
>

Re: BGP Redistribution question

[Simen Stavdal]

2   # private space [RFC1918]
192.0.2.0/24# TEST-NET-1 [RFC5737]
192.88.99.0/24  # 6to4 anycast relay [RFC7526]
#192.168.0.0/16 # private space [RFC1918]
198.18.0.0/15   # benchmarking [RFC2544]
198.51.100.0/24 # TEST-NET-2 [RFC5737]
203.0.113.0/24  # TEST-NET-3 [RFC5737]
224.0.0.0/4 # multicast
240.0.0.0/4 # reserved for future use
::/8# RFC 4291 IPv4-compatible, loopback, et al
0100::/64   # Discard-Only [RFC]
2001:2::/48 # BMWG [RFC5180]
2001:10::/28# ORCHID [RFC4843]
2001:db8::/32   # docu range [RFC3849]
2002::/16   # 6to4 anycast relay [RFC7526]
3ffe::/16   # old 6bone
fc00::/7# unique local unicast
fe80::/10   # link local unicast
fec0::/10   # old site local unicast
ff00::/8# multicast
}

network prefix-set mynetworks set large-community $ASN:1:1
network inet priority 32

group "ibgp mesh v4" {
remote-as $ASN
# use loopback for IBGP sessions, assume its distributed in OSPF
local-address 192.168.2.1
neighbor 192.168.2.2# 4nic2
}

allow to ebgp prefix-set mynetworks large-community $ASN:1:1

deny quick from ebgp prefix-set mynetworks or-longer

allow from ibgp
allow to ibgp

match from 192.168.2.2 set rtlabel zyx

match from ebgp set { community delete $ASN:* }
match from ebgp set { large-community delete $ASN:*:* }

allow from any inet prefixlen 8 - 24
allow from any inet6 prefixlen 16 - 48

match from any community GRACEFUL_SHUTDOWN set { localpref 0 }

deny quick from any prefix-set bogons or-longer

deny quick from any AS 23456
deny quick from any AS 64496 - 131071
deny quick from any AS 42 - 4294967295

deny from any max-as-len 100


network inet priority 32 is used to redistribute ospf into bgp.


Hope it makes more sense now.

Simply, how can I get router B to advertise (or label) the directly
connected network (192.168.2.0/30) so that I can re-advertise into
OSPF.

Is there a way to add a label to a directly connected network? Can I
get router C to advertise this, and then use router B to label? etc


Cheers,

Simon.




On Mon, 14 Jan 2019 at 22:06, Sebastian Benoit  wrote:

> Hi,
>
> Simen Stavdal(sstav...@gmail.com) on 2019.01.14 21:29:43 +0100:
> > Hello,
> >
> > I have three routers connected in a  chain.
> > A<->B<->C
> >
> > All routers have a host address as loopback 100 (192.168.5.x/32, A=1,
> B=2,
> > C=3).
> > The segments between the routers are 192.168.1.0/30 (AB) and
> 192.168.2.0/30
> > (BC).
> >
> > A to B runs OSPF
> > B to C runs IBGP
> >
> > I redistribute the BGP routes into OSPF using the label I append on
> router
> > B.
> > router B : match from  set rtlabel zyx
> > And this works just fine. I see the tag being applied (but only on the
> > advertised lo100 host address).
> > Reverse redistribution is based on route priority (32) for OSPF into bgp.
> > All good.
> >
> > The link network however between B and C is not being advertised, as it
> is
> > locally connected for both router B and C. They are added in the network
> > statement on both sides.
> > So, on B, I can see the route label on the C loopback interface marked
> zyx.
> > 192.168.2.0/30 however does not have any route label, and hence will
> not be
> > redistributed into OSPF.
> >
> > So, I can ping router C from router B.
> > When I ping loopback on router C from router A using the loopback
> interface
> > as source, all is good.
> > When I ping with no source interface, the source address is the link
> > network not being advertised, and hence the far router does not know
> where
> > to send the traffic.
> >
> > I will continue to play around with this, just wondering if anybody has a
> > "good practice" way of dynamically advertising the network.
>
> Your mail is missing
>
> - what version of openbsd you are running, i.e. dmesg
>
> - your bgpd.conf and ospfd.conf files would be helpful.
>
> - you describe what you have currently configured, but not what your actual
> intent is. It may be better if you say what you want your network devices
> to
> do.
>
> That said, if i understand what you are doing right, maybe
> "network inet connected" on router B bgpd.conf will help.
> (you may also need filters to allow the prefix to be sent to C).
>
> /Benno
>

BGP Redistribution question

[Simen Stavdal]

Hello,

I have three routers connected in a  chain.
A<->B<->C

All routers have a host address as loopback 100 (192.168.5.x/32, A=1, B=2,
C=3).
The segments between the routers are 192.168.1.0/30 (AB) and 192.168.2.0/30
(BC).

A to B runs OSPF
B to C runs IBGP

I redistribute the BGP routes into OSPF using the label I append on router
B.
router B : match from  set rtlabel zyx
And this works just fine. I see the tag being applied (but only on the
advertised lo100 host address).
Reverse redistribution is based on route priority (32) for OSPF into bgp.
All good.

The link network however between B and C is not being advertised, as it is
locally connected for both router B and C. They are added in the network
statement on both sides.
So, on B, I can see the route label on the C loopback interface marked zyx.
192.168.2.0/30 however does not have any route label, and hence will not be
redistributed into OSPF.

So, I can ping router C from router B.
When I ping loopback on router C from router A using the loopback interface
as source, all is good.
When I ping with no source interface, the source address is the link
network not being advertised, and hence the far router does not know where
to send the traffic.

I will continue to play around with this, just wondering if anybody has a
"good practice" way of dynamically advertising the network.

Cheers,
Simon.

Re: Ospf adding new interface

[Simen Stavdal]

So, with 6.4 recently released, I just installed it rather than using
latest current - worked flawlessly - thank you.

ospfctl reload now picks up new interfaces added.

/S

On Sat, 29 Sep 2018 at 13:40, Stuart Henderson  wrote:

> On 2018/09/29 13:36, Simen Stavdal wrote:
> > Thanks Stuart,
> >
> > -vd just said the same, i.e interface unknown, will try -current and
> report back :)
>
> If it doesn't help, it would also be worth capturing "route -n monitor"
> output while adding.
>
>
>
> > Thanks,
> > Simon
> >
> > On Sat, 29 Sep 2018 at 13:06, Stuart Henderson 
> wrote:
> >
> > I've had problems at times with ospfd not seeing interfaces properly
> > after adding them, please try a -current snapshot and see if you can
> > replicate it, it's possible that a change made in June might help.
> >
> > Also maybe try running with ospfd -vd and see if you get anything
> unusual
> > logged when the interface is added or when you issue 'reload'.
> >
> >
> >
>

Re: Ospf adding new interface

[Simen Stavdal]

Thanks Stuart,

-vd just said the same, i.e interface unknown, will try -current and report
back :)

Thanks,
Simon

On Sat, 29 Sep 2018 at 13:06, Stuart Henderson  wrote:

> I've had problems at times with ospfd not seeing interfaces properly
> after adding them, please try a -current snapshot and see if you can
> replicate it, it's possible that a change made in June might help.
>
> Also maybe try running with ospfd -vd and see if you get anything unusual
> logged when the interface is added or when you issue 'reload'.
>
>
>

Re: Ospf adding new interface

[Simen Stavdal]

Thanks Remi,
I am doing almost exactly that too

My setup:
mgmt--6.3amd64<-rdomain0->6.3octeon-mgmt
Ospf is running inside rdomain0.

Scenario:
On amd64 : I have a few loopback interfaces running, and routing works ok.
Example, lo17 is advertised as 192.168.17.144/32
On octeon : I can ping 192.168.17.144, and it is showing expected egress
interfaces etc
On amd : cp /etc/hostname.lo17 /etc/hostname.lo13
I give lo13 the address of 192.168.13.144/32
I bring it up with sh /etc/netstart lo13
I ping it locally ok
I add the interface as passive in ospfd.conf like you described above,
syntax is good.
I issue ospfctl reload
In /var/log/messages, it says lo13
Sep 29 12:20:18 4nic2 ospfd[33900]: /etc/ospfd.conf:32: unknown interface
lo13
Sep 29 12:20:18 4nic2 ospfd[33900]: configuration reload failed

On octeon : new interface is obviously not seen.
On amd64 : restart the entire ospfd daemon (as opposed to ospfctl reload),
config file now reads ok, no issue.
On octeon : I now can see the advertised lo13 address, and ping it. routing
table looks as expected.

So, I know my syntax is good, because it works when I restart the daemon,
it just happens when I try reloading it.

My setup may be a little different to yours though.
I have a mangement interface that I use to connect to my lab, running in
routing domain 1.
After logging in, I issue a "route -T0 exec ksh" to work inside routing
domain 0.
I have verified that all processes run in the expected routing domains.
Also, I have issued all daemons and reload processes to be executed in
rdomain 0.
i.e route -T0 exec ospfctl reload

I am wondering why ospfd can't see the new interface while running, but it
does after completely restarting the daemon.
I am starting ospfd from command line, not with rc flags, because I am
still testing.
Have tried daemonized and with "-d" flag - both demonstrate the same issue.

Btw, when I reverse it, i.e creating the lo interfaces on the octeon box, I
see the same problem.

Cheers,
Simon.

On Fri, 28 Sep 2018 at 23:41, Remi Locherer  wrote:

> Hi Simon
>
> On Fri, Sep 28, 2018 at 10:22:42PM +0200, Simen Stavdal wrote:
> > Hi all,
> >
> > On 6.3, using both octeon and amd64.
> >
> > While ospfd is running, I would like to add another interface (let’s say
> a
> > loopback if). After  adding the loopback if to ospf as passive I reload
> > with ospfctl, but it does not start advertising the new interface. Only
> > when I restart ospfd will it start doing so, but it seems a bit intrusive
> > as all neighbours will recalculate. I am sure that something basic had
> > slipped my mind. Any way to make it register the new if?
> >
> > The config is working since it does pick up the if on ospfd restart.
> >
>
> When I do what you describe the route is immediate seen by other ospf
> router. I quickly checked on amd64 -current VMs. I did this many times
> in the last few years and it always worked for me.
>
> I tested now with this config:
>
> r2# cat /etc/ospfd.conf
> router-id 192.168.250.102
>
> area 0.0.0.0 {
> interface vio0
> interface vlan1
> }
>
>
> Then I started ospfd and created lo33. After that I added this line to
> ospfd.conf:
>interface lo33 { passive }
>
> Then I did "ospfctl reload" and the expectd route appeared in neighbor's
> routing table.
>
> Regards,
> Remi
>

Ospf adding new interface

[Simen Stavdal]

Hi all,

On 6.3, using both octeon and amd64.

While ospfd is running, I would like to add another interface (let’s say a
loopback if). After  adding the loopback if to ospf as passive I reload
with ospfctl, but it does not start advertising the new interface. Only
when I restart ospfd will it start doing so, but it seems a bit intrusive
as all neighbours will recalculate. I am sure that something basic had
slipped my mind. Any way to make it register the new if?

The config is working since it does pick up the if on ospfd restart.

Cheers,
Simon

Adding interfaces to ospf

[Simen Stavdal]

Hello,

I am setting up an ospf lab, and have a quick question.
The answer is probably right in front of me, but I just can't seem to find
it.

I have a basic ospfd.conf including some active and some passive interfaces.
Working just fine.

usg2# cat /etc/ospfd.conf | grep -v "^#"
password="secret"
redistribute connected
area 0.0.0.0 {
interface lo2 { passive }
interface lo11 { passive }
interface lo10 { passive }
interface cnmac0 {
auth-type simple
auth-key $password
}
}


I have a neighbour that sees all the routes advertised from usg2.

Then, I would like to add a loopback interface on one of the routers, give
it a /32 and advertise it (like i already do for some other loopback
interfaces).

Next, how do I get ospf to advertise the new host address?

I have tried :
ospfctl reload
Obviously I have not yet changed ospfd.conf, so I add the new loopback
interface as passive.
ospfctl reload again, no luck.

usg2# ifconfig lo12 inet 192.168.5.111 netmask 255.255.255.255 up
   usg2# ifconfig lo12
lo12: flags=8049 mtu 32768
index 19 priority 0 llprio 3
groups: lo
inet 192.168.5.111 netmask 0x


usg2# ospfctl show fib
flags: * = valid, O = OSPF, C = Connected, S = Static
Flags  Prio Destination  Nexthop
*C4 10.10.100.0/24   link#1
*C0 127.0.0.0/8  link#0
*S8 127.0.0.0/8  127.0.0.1
* 1 127.0.0.1/32 127.0.0.1
*O   32 192.168.1.1/32   10.10.100.2
* 1 192.168.5.9/32   192.168.5.9
* 1 192.168.5.10/32  192.168.5.10
* 1 192.168.5.99/32  192.168.5.99
* 1 192.168.5.111/32 192.168.5.111
*S8 224.0.0.0/4  127.0.0.1

So, it is seen in the fib.

usg2# ospfctl fib couple
 couple request sent.


On one of the neighbours, I can see all the locally connected from
usg2, but not lo12 (which is the new one I just added).


The only way I have found so far, is to restart the ospfd daemon, but
that seems a bit excessive - recalculations and all that. By the way,
I am running ospfd with "-d" - do not daemonize. Any suggestions?

Running OpenBSD 6.3, tried on octeon and amd64, same behaviour.

I will be happy to supply any information requested.


Cheers,

Simon.

Re: Serving multiple domains on one machine or IP address

[Simen Stavdal]

Hi Greg,

I haven't done this myself, but take a look at the man pages of httpd.conf
under the servers sections.
You can create multiple a-records pointing to the same ip address, and then
pick up the incoming traffic by inspecting the http header in order to find
which virtual server to send the traffic.

Simon.

On 19 September 2017 at 07:46, Niels Kobschaetzki 
wrote:

>
> > On 19. Sep 2017, at 07:17, Greg Garrison  wrote:
> >
>
> 
>
> > Additionally I notice that the default client HTTP error messages (e.g.
> 404 error) that HTTPD generates reveal that the server is running OpenBSD.
> This is not a big deal but if the error messages were configurable so that
> they could mask the server OS or could display an otherwise custom message
> I would see value in that. Does this capability exist with without
> recompiling HTTPD?
>
> Being curious: Why do you want to mask the server-OS in the error message?
>
> Niels
>

Re: Topics for revised PF and networking tutorial

[Simen Stavdal]

Anycast with ospf and ipv6 could be a fun tutorial...

/S

On 2 Apr 2017 22:27, "Luke Small"  wrote:

> It might be a fun idea to share what a really locked down desktop system
> pf.conf would look like like if you are running a chain of DNS services (or
> something that would be good to tightly control) like local ntpd, unbound,
> and dnscrypt_proxy where you have local traffic locked down as well so that
> an aberrant process or even root cannot connect to the local ports and
> services eg.
>
> pass out quick on lo0 proto {tcp, udp} from self to any port 53 user
> {peter, _ntpd}
>
> block out log quick on lo0 proto {tcp, udp} from self to any port 53
>
>
> pass in quick on lo0 proto {tcp, udp} from any to self port 53 user
> _unbound
>
> block in log quick on lo0 proto {tcp, udp} from any to self port 53
>
>
>
> pass out quick on lo0 proto {tcp, udp} from self to any port 40 user
> _unbound
>
> block out log quick on lo0 proto {tcp, udp} from self to any port 40
>
>
> pass in quick on lo0 proto {tcp, udp} from any to self port 40 user
> _dnscrypt_proxy
>
> block in log quick on lo0 proto {tcp, udp} from any to self port 40
>
>
> pass out quick on egress proto {tcp, udp} from self to any port 53  user
> _dnscrypt_proxy
>
> block out log quick on egress proto {tcp, udp} from self to any port 53
>
> Maybe there is a similar case that can be made, possibly with a reverse
> http proxy setup that would make more sense for security in the case that a
> vulnerability is discovered.

Re: OpenVPN problem.

[Simen Stavdal]

and...

do you have the routing table for some of the hosts that can/cannot ping 
each other?

Are there other gateways out of the networks, other than the openvpn box?

S.

Alessandro Baggi wrote:

Johan Beisser wrote:

On Mon, Jan 25, 2010 at 10:05 AM, Alessandro Baggi
alessandro.ba...@gmail.com wrote:
 

Johan Beisser wrote:



 

Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and
server side to:

ext=rl0
int=rl1

nat on $ext from $int:network - $ext:0
nat on tun0 from $int:network - tun0:0

pass all



What version of OpenBSD are you running?

 
I can ping from client LAN of the vpn client the entire Server side 
lan, but

not viceversa.



Are you certain your packets are being natted properly?

  

On server side 4.5 updated to 4.6 and client side 4.6.
Packet from server side network are natted, with tcpdump on tun0, I 
get 10.0.8.1 - 192.168.7.2 but I don't receive an answer.

I can ping client side (10.0.8.6) from server (10.0.8.1)
I can ping and ssh to client server side (10.1.0.0/16) from 
192.168.7.0/24

Re: OpenVPN problem.

[Simen Stavdal]

Hello Alessandro,

Can you see any of the traffic on the inside LAN on the client side with 
tcpdump?


I.e set tcpdump on $int with
tcpdump -i nameofinternalinterface proto icmp

and then try to ping from a server?

Silly suggestion, but
What about client side firewalls? Do they allow to be pinged?

What is your server.conf file for openvpn and the client conf file?

Simon.

Alessandro Baggi wrote:

Johan Beisser wrote:

On Mon, Jan 25, 2010 at 5:45 AM, Alessandro Baggi
alessandro.ba...@gmail.com wrote:
 

Hi list! I'm setting up a vpn between two openbsd firewall:
This is the scenario:

FW1  FW2
$ext 192.168.1.33  $ext 192.168.1.2
$int 10.1.1.1   $int 192.168.7.1

$host 10.1.3.53   $host2 192.168.7.2

then I've made the certificate, client can contact the server, and 
from the
client I can ping a Linux Machine behind the server, and from linux 
machine

to client.
Then I've tried to get communication with LAN clients behind the VPN 
client
gw. Then, 192.168.7.2 of FW2's VPN can comunicate with 10.1.3.53, 
but not

viceversa.



Are you permitting traffic from $host through the firewall?

What's your pf.conf?

Have you verified that your firewalls pass other traffic normally?

  
Hi Johan. Thanks for the answer. I've reduced my pf.conf on client and 
server side to:


ext=rl0
int=rl1

nat on $ext from $int:network - $ext:0
nat on tun0 from $int:network - tun0:0

pass all

I can ping from client LAN of the vpn client the entire Server side 
lan, but not viceversa.

Re: OpenVPN problem.

[Simen Stavdal]

Ciao Alessandro,

So, from the server, the client gets allocated 10.0.8.5/32
(btw, probably a minor thing, but in your server conf file, you have a 
mismatch on the host/mask when you push the routes- it reads

push route 10.1.1.1 255.255.0.0  while it should read 10.1.0.0)
(doesn't seem to bother the client too much, but it might be worth a try 
to correct it).


Also, on the server side routing table, you have the following :
192.168.7/24  10.0.8.2   UGS0  175 - 
8 tun0


Where is 10.0.8.2?
This is from the pool of client addresses, but does not exist anywhere?

You also have som route statements in your server conf file, like this one :
route 192.168.7.0 255.255.255.0
It doesn't have a gateway, and is not locally connected
This tells the client host to route 192.168.7.0 to nowhere (even though 
it is locally connected on the client side).


On my config, the client side routing table looks like this (windows host) :
   10.10.177.0255.255.255.0  10.10.177.5 10.10.177.6   1
   10.10.177.4  255.255.255.252  10.10.177.6 10.10.177.6   30


Also, the two hosts are not connected with public addresses, can I ask 
why you want to use NAT between to RFC1918 networks that don't overlap?
I am trying to understand your objective and the purpose of the setup, 
maybe there is a different way of setting it up?


Cheers,
Simon.


Alessandro Baggi wrote:

Simen Stavdal wrote:

and...

do you have the routing table for some of the hosts that can/cannot 
ping each other?
Are there other gateways out of the networks, other than the openvpn 
box?


S.


I'm trying openvpn in my internal network:
 
   internet

 |
   primary node
192.168.1.1
/  
   \
  OBSD  
OBSD 2

  192.168.1.33   192.168.1.2
  10.1.0.0/16   
192.168.7.0/24
   |  
  |
. 
   .

Re: Filtering scp ssh and sftp

[Simen Stavdal]

 Hi Chris,

Thanks for the advise. I never though of doing it this way... - :)
The ssh-part of it is just for administration of the box, so it can run
on a non-standard port number, but I see your point.
If there had been normal users, I would use two different machines.

Cheers,
Simon.

Chris Dukes wrote:

  On Mon, Sep 28, 2009 at 11:28:51PM +0200, Simen Stavdal wrote:

Hello misc,

I have an openbsd host running that I wish to access in different
manners depending on where the users connect from.
This host runs sftp chrooted for internet users, and at the same
time, I wish to administer the box with ssh.
At the same time, I do not wish to allow ssh from the internet. We
have a policy that only vpn connected users can administer local
systems.
The host is located on a dmz with one interface and one public ip address.

Between the users, the internet and this server I have two firewalls
running openbsd 4.1 GENERIC.MP (with Carp over Vlan over trunk).

Internet -Firewall---DMZ with SFTP server
|
  Internal users

I want to allow all ssh services for internal users, and sftp _only_
from the internet.
Since sftp/scp/ssh all run on the same port number (22 default), is
there a way to filter the traffic with pf?
I've seen that you can queue the traffic with ALTQ, but is there a
way to block/allow before this stage?
Any best practice on the subject?

  Two sshd_configs.  One locked down to sftp only running on a non-standard
  port and one with the services for internal users on the standard port.
  Tell your users to use the non-standard port for external use.
  If your users aren't bright enough to be able to use a non-standard port, 
  have a redirect rule on one of the firewalls that changes the 
  destination port.
  
  Personally, I'd try and split the internal traffic and external traffic
  different machines and if that wasn't possible to different NICs on
  different subnets.

Cheers,
Simon.

Filtering scp ssh and sftp

[Simen Stavdal]

Hello misc,

I have an openbsd host running that I wish to access in different 
manners depending on where the users connect from.
This host runs sftp chrooted for internet users, and at the same time, I 
wish to administer the box with ssh.
At the same time, I do not wish to allow ssh from the internet. We have 
a policy that only vpn connected users can administer local systems.

The host is located on a dmz with one interface and one public ip address.

Between the users, the internet and this server I have two firewalls 
running openbsd 4.1 GENERIC.MP (with Carp over Vlan over trunk).


Internet -Firewall---DMZ with SFTP server
|
  Internal users

I want to allow all ssh services for internal users, and sftp _only_ 
from the internet.
Since sftp/scp/ssh all run on the same port number (22 default), is 
there a way to filter the traffic with pf?
I've seen that you can queue the traffic with ALTQ, but is there a way 
to block/allow before this stage?

Any best practice on the subject?

Cheers,
Simon.

Re: OT: 10GbE Physical Network Taps

[Simen Stavdal]

Hello jcr,

Not quite sure if this would meet your needs, but you could look at anue
systems :

http://www.anuesystems.com

Cheers,
Simon.

On Wed May 6 13:33 , J.C. Roberts sent:

  I need to collect raw throughput statistics without increasing
  latency
  or reducing bandwidth on 10GbE fiber links, so most of the typical
  methods are out of the question (i.e. like bridging, SPAN sessions on
  a
  switch, ...). As far as my understanding allows, I believe the best
  way
  to do this is with a physical network tap connected to monitoring
  equipment. I figure folks running/maintaining OpenBSD firewalls might
  be familiar with using physical network taps for deploying IDS/IPS
  since
  using bridges on such systems is a Bad Idea (R)(TM).

  I've found one company [1] which offers what I need, but I was
  wondering
  if anyone can recommend a vendor of physical network taps?

  Thanks,
  jcr

  [1] http://www.networktaps.com/products/index.html

  --
  J.C. Roberts

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Static IP address problems

[Simen Stavdal]

Hello,

What sort of box is your default gateway?
(Possibilities for running tcpdump on the gateway?)
If you do, you could check the interfaces on the gateway, that the
packets get routed to another interface on the gateway.
There could be a number of configuration options on the gateway producing
the problems you see, including :
1. Firewall allowing only certain addresses.
2. Network Address Translation mapping only to certain addresses.

You could try to use an unused address from the dhcp pool and assign this
statically for testing.

Presumably when you say you can ssh into the box, your ssh client is on
the same subnet?
Name resolution could be proxied at the gateway, explaining why that
works.
I would take a close look at your gateway configuration.

You could also check that the routing table selects the right outgoing
gateway.
Check with
route get 1.2.3.4
This should produce something like :
route to: 1.2.3.4
destination: default
mask: default
gateway: x.x.x.x
interface: vlan10

This would test that the routing table not only looks right, but that the
right routing decision is made.

Cheers,
Simon.

On Fri Feb 27 10:20 , Ruan Kendall sent:

  I've come across a strange problem whereby configuring an interface
  with DHCP lets my system run absolutely fine, but assigning a static
  IP to the nic results in a system that can only speak to the local
  subnet. I can ssh into it, but cannot connect to any machines on the
  internet. The computer and internet connection are otherwise quite
  functional.

  In both cases, the adresses are in the same subnet, have the same
  subnet mask and default gateway. Output of ifconfig and route -rn
  look
  all but identical. In both cases, name resolution works just fine
  also. Tcpdump shows that when I ping a machine external to my subnet,
  outgoing packets are sent to the MAC address of my router. Only in
  the
  case of the statically configured adress, I never get any response.

  Handful of diagnostic information shown below. Evidently, I'm doing
  something stupid and wrong, but I seem to be quite unable to
  recognise
  what on earth it is. Does anyone have any suggestions?

  When dhclient is used to configure interface (by doing dhclient
  sis0):

  ifconfig sis0
  sis0: flags=8843 mtu 1500
  lladdr 00:00:24:c3:d6:cc
  groups: egress
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active
  inet6 fe80::200:24ff:fec3:d6cc%sis0 prefixlen 64 scopeid 0x1
  inet 192.168.1.34 netmask 0xff00 broadcast 192.168.1.255

  netstat -rn, minus ipv6 stuff
  Destination Gateway Flags Refs Use Mtu Prio Iface
  default 192.168.1.1 UGS 0 2 - 48 sis0
  127/8 127.0.0.1 UGRS 0 0 33204 48 lo0
  127.0.0.1 127.0.0.1 UH 2 0 33204 48 lo0
  192.168.1/24 link#1 UC 1 0 - 48 sis0
  192.168.1.1 00:13:49:b0:cb:91 UHLc 1 1 - 48 sis0
  192.168.1.34 127.0.0.1 UGHS 0 0 33204 48 lo0
  224/4 127.0.0.1 URS 0 0 33204 48 lo0

  When adress is configured using following hostname.if file (either by
  rebooting the box, or running /etc/netstart):
  inet 192.168.1.200 255.255.255.0 NONE

  ifconfig sis0
  sis0: flags=8843 mtu 1500
  lladdr 00:00:24:c3:d6:cc
  groups: egress
  media: Ethernet autoselect (100baseTX full-duplex)
  status: active
  inet 192.168.1.200 netmask 0xff00 broadcast 192.168.1.255
  inet6 fe80::200:24ff:fec3:d6cc%sis0 prefixlen 64 scopeid 0x1

  netstat -rn, minus ipv6 stuff
  Destination Gateway Flags Refs Use Mtu Prio Iface
  default 192.168.1.1 UGS 0 3 - 48 sis0
  127/8 127.0.0.1 UGRS 0 0 33204 48 lo0
  127.0.0.1 127.0.0.1 UH 1 0 33204 48 lo0
  192.168.1/24 link#1 UC 1 0 - 48 sis0
  192.168.1.1 00:13:49:b0:cb:91 UHLc 1 1 - 48 sis0
  224/4 127.0.0.1 URS 0 0 33204 48 lo0

  Adding !route add default 192.168.1.1 to the end of the hostname.if
  file has no effect. Adding in a route from 192.168.1.200 to 127.0.0.1
  mimicking the extra route dhclient sets up has no effect.

-
Fe din egen, gratis e-postadresse pe Start.no

Re: why wont my vlan interface accept this /28 ?

[Simen Stavdal]

Hello,

I've had a similar issue before, and cannot quite remember in detail, but
it was something like this ;

Check that you have a /etc/hostname.vlan203 config file, and modify the
netmask here.
Do you have any carp interfaces layered over vlan203 that may be
conflicting with the netmask?
If you do, correct this, and then issue a destroy on the carp interface
(if any), than the vlan interface, followed by sh /etc/netstart vlan203 ;
sh /etc/netstart carp203 (or other carp name if any).

So, summarised :
ifconfig | grep carp | grep vlan # Will tell you if you have vlandev 203
in use by any carp interfaces.
if you do, note the carp interface name (let's call it carp203).
Then, correct your /etc/hostname.vlan203 and /etc/hostname.carp203 files
with the correct netmask.
Then, issue a :
ifconfig carp203 destroy ; ifconfig vlan203 destroy ; sh /etc/netstart
vlan203 ; sh /etc/netstart carp203

This worked for me at least...

Cheers,
Simon

On Fri Feb 6 14:32 , Charlie Allom sent:

  Hi!

  There is some subtelty here which I cannot distinguish.. There is
  another host on the same segment with 94.228.79.226/0xfff0 if
  that
  helps? I will put a carpN on 94.228.79.225/28.

  anyway the problem is this: I can't seem to assign the /28 to this
  new
  vlan interface:

  13:16 trajan:~# ifconfig vlan203 inet 94.228.79.227
  13:16 trajan:~# ifconfig vlan203 inet 94.228.79.227 netmask
  0xfff8
  13:17 trajan:~# ifconfig vlan203 inet 94.228.79.227 netmask
  0xfff0
  ifconfig: SIOCAIFADDR: File exists

  whhaatt? others work?

  13:19 trajan:~# uname -a
  OpenBSD trajan.playlouder.com 4.3 GENERIC.MP+RAIDFRAME#2 i386

  13:24 trajan:~# ifconfig
  lo0: flags=8049 mtu 33208
  groups: lo
  inet 127.0.0.1 netmask 0xff00
  inet6 ::1 prefixlen 128
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
  em0: flags=8843 mtu 1500
  lladdr 00:30:48:33:52:fa
  description: mgmt
  media: Ethernet autoselect (1000baseT full-duplex,master)
  status: active
  inet 10.0.1.28 netmask 0xff00 broadcast 10.0.1.255
  inet6 fe80::230:48ff:fe33:52fa%em0 prefixlen 64 scopeid 0x1
  em1: flags=8843 mtu 1500
  lladdr 00:30:48:33:52:fb
  description: pfsync
  media: Ethernet autoselect (1000baseT
  full-duplex,master,rxpause,txpause)
  status: active
  inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255
  inet6 fe80::230:48ff:fe33:52fb%em1 prefixlen 64 scopeid 0x2
  em2: flags=8943 mtu 1500
  lladdr 00:15:17:14:ec:9c
  description: trajan
  media: Ethernet autoselect (1000baseT full-duplex)
  status: active
  inet 193.34.28.3 netmask 0xfe00 broadcast 193.34.29.255
  inet6 fe80::215:17ff:fe14:ec9c%em2 prefixlen 64 scopeid 0x3
  inet6 2a01:450:1000:57ab::3 prefixlen 64
  em3: flags=8943 mtu 1500
  lladdr 00:15:17:14:ec:9d
  description: transit
  groups: egress
  media: Ethernet autoselect (1000baseT full-duplex)
  status: active
  inet 89.200.217.3 netmask 0xffe0 broadcast 89.200.217.31
  inet6 fe80::215:17ff:fe14:ec9d%em3 prefixlen 64 scopeid 0x4
  inet6 2a01:450:1000:10c8::3 prefixlen 64
  em4: flags=8943 mtu 1500
  lladdr 00:15:17:14:ec:9e
  media: Ethernet autoselect (1000baseT full-duplex)
  status: active
  inet6 fe80::215:17ff:fe14:ec9e%em4 prefixlen 64 scopeid 0x5
  em5: flags=8943 mtu 1500
  lladdr 00:15:17:14:ec:9f
  media: Ethernet autoselect (1000baseT full-duplex)
  status: active
  inet6 fe80::215:17ff:fe14:ec9f%em5 prefixlen 64 scopeid 0x6
  enc0: flags=0 mtu 1536
  pfsync0: flags=41 mtu 1460
  pfsync: syncdev: em1 syncpeer: 224.0.0.240 maxupd: 128
  groups: carp pfsync
  pflog0: flags=141 mtu 33208
  groups: pflog
  vlan203: flags=8843 mtu 1500
  lladdr 00:15:17:14:ec:9c
  vlan: 203 priority: 0 parent interface: em2
  groups: vlan
  inet6 fe80::215:17ff:fe14:ec9c%vlan203 prefixlen 64 scopeid 0xe
  carp0: flags=8843 mtu 1500
  lladdr 00:00:5e:00:01:15
  description: gateway
  carp: BACKUP carpdev em2 vhid 21 advbase 1 advskew 100
  groups: carp
  inet6 fe80::200:5eff:fe00:115%carp0 prefixlen 64 scopeid 0x9
  inet 193.34.28.1 netmask 0xfe00 broadcast 193.34.29.255
  carp1: flags=8843 mtu 1500
  lladdr 00:00:5e:00:01:16
  description: incoming gateway
  carp: BACKUP carpdev em3 vhid 22 advbase 1 advskew 100
  groups: carp
  inet6 fe80::200:5eff:fe00:116%carp1 prefixlen 64 scopeid 0xa
  inet 89.200.217.1 netmask 0xffe0 broadcast 89.200.217.31
  carp2: flags=8843 mtu 1500
  lladdr 00:00:5e:00:01:17
  description: ci-gateway
  carp: BACKUP carpdev em2 vhid 23 advbase 1 advskew 100
  groups: carp
  inet6 fe80::200:5eff:fe00:117%carp2 prefixlen 64 scopeid 0xb
  inet 193.34.29.1 netmask 0xff00 broadcast 193.34.29.255

  --
  020 7729 4797
  http://blog.playlouder.com/

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: pkg_add adds an extra / to pkg_path

[Simen Stavdal]

Hello,

Checking on my own box (running 4.1), $PKG_PATH echoes ;
ftp://ftp.stacken.kth.se/pub/OpenBSD/4.1/packages/i386/
# uname -a
OpenBSD ## 4.1 GENERIC.MP#1225 i386

I have
export PKG_PATH=ftp://ftp.stacken.kth.se/pub/OpenBSD/4.1/packages/i386/
Set in my .profile, and it works for me.

From the error message you are getting, it seems it cannot find the host
ftp.openbsd.org...
Can you connect to it from a command line (i.e ftp ftp.openbsd.org)?
Also, make sure that your uname -r corresponds with the version directory
for the ftp path...

Simon.

On Tue Feb 3 8:51 , Siju George sent:

  Hi,

  I have this in my PKG_PATH variable

  $ echo $PKG_PATH
  ftp://ftp.openbsd.org/pub/OpenBSD/4.4/packages/i386/
  $

  When I try to update a package it shows an error

  $ sudo pkg_add -ui firefox3
  Error from ftp://ftp.openbsd.org//pub/OpenBSD/4.4/packages/i386/:
  ftp: connect: Connection refused
  ftp: Can't connect or login to host `ftp.openbsd.org'
  No packages available in the PKG_PATH
  Looking for updates: complete
  Cannot find updates for esound-0.2.38v0 glitz-0.5.6p0
  firefox3-3.0.1p3
  nspr-4.7.1p0 desktop-file-utils-0.15 libaudiofile-0.2.6p0 nss-3.12
  hicolor-icon-theme-0.10p1 png-1.2.28 sqlite3-3.5.9p0 jpeg-6bp3
  glib2-2.16.4p1 tiff-3.8.2p0 atk-1.22.0 libiconv-1.12 pango-1.20.0p0
  cairo-1.6.4 gettext-0.17 pcre-7.7p0 gtk+2-2.12.11
  Proceed? [y/N] y
  $

  I noticed in the line

  Error from ftp://ftp.openbsd.org//pub/OpenBSD/4.4/packages/i386/:

  there are two forward slashes after the ftp.openbsd.org part.

  Is that what is causing the trouble?
  How do I solve this?

  Thanks

  --Siju

-
Fe din egen, gratis e-postadresse pe Start.no

Re: Detecting heavy traffic users

[Simen Stavdal]

Hi Ricardo/list,

You could also use pfflowd (which exports netflow compatible datagrams).
Then you could set up ntop as a receiver, to give you long term stats.

Cheers,
Simon.

On Thu Jan 15 15:24 , Ricardo Augusto de Souza sent:

  Hi list,

  i have an openBSD 4.3 with PF as a gateway/router.
  My users go to the internet and to other networks through this
  server.
  I am still have no bw control, but i will implement it asap.

  I am used to monitoring bw using this tool:

  bwm-ng v0.6 (probing every 0.500s), press 'h' for help
  input: getifaddrs type: rate
  / iface Rx Tx
  Total
  ===
  ===
  lo0: 0.00 KB/s 0.00 KB/s 0.00
  KB/s
  bge0: 117.30 KB/s 16.26 KB/s 133.56
  KB/s
  bge1: 40.39 KB/s 2.91 KB/s 43.30
  KB/s
  xl0: 16.76 KB/s 159.42 KB/s 176.17
  KB/s
  xl1: 0.00 KB/s 0.00 KB/s 0.00
  KB/s
  tun0: 0.00 KB/s 0.00 KB/s 0.00
  KB/s
  pflog0: 0.00 KB/s 0.00 KB/s 0.00
  KB/s
  tun1: 0.00 KB/s 0.00 KB/s 0.00
  KB/s
  ---
  ---
  total: 174.44 KB/s 178.59 KB/s 353.03
  KB/s

  bge1 = internet A
  xl1 = internet B ( backup )
  bge0 = mpls ( network 10.100.0.0/25 )
  xl0 = lan

  bge0 is a 1 mbits/s link to my DataCenter. As you can see its with a
  high
  traffic right now.
  When this happens, i use tcpdump to try identify what is the IP with
  this high
  traffic.
  I read a lot about tcpdump advanced filtering but i couldn4t get it
  yet.

  # tcpdump -i xl0 dst net 10.100.0
  tcpdump: listening on xl0, link-type EN10MB
  11:58:13.444535 10.10.0.85.3686  10.100.0.20.1521: P
  1718388167:1718388351(184) ack 3906805828 win 64674 (DF)
  11:58:13.445633 10.10.0.37.4240  10.100.0.20.1521: P
  4245905889:4245905926(37) ack 739870590 win 65350 (DF)
  11:58:13.455229 10.10.0.59.3748  10.100.0.20.1521: P
  3266944936:3266945123(187) ack 1986329831 win 65535 (DF)
  11:58:13.463196 10.10.0.33.4449  10.100.0.20.1521: P
  2765663668:2765663713(45) ack 3349351703 win 65535 (DF)
  11:58:13.463314 10.10.0.85.3686  10.100.0.20.1521: P 184:229(45) ack
  71 win
  64604 (DF)
  11:58:13.465625 10.10.0.37.4240  10.100.0.20.1521: P 37:163(126) ack
  70 win
  65281 (DF)
  11:58:13.478123 10.10.0.101.1362  10.100.0.4.5900: . ack 2761513569
  win 65535
  (DF)
  11:58:13.478949 10.10.0.101.1362  10.100.0.4.5900: P 0:10(10) ack 1
  win 65535
  (DF)
  11:58:13.481370 10.10.0.59.3748  10.100.0.20.1521: P 187:1114(927)
  ack 166
  win 65370 (DF)
  11:58:13.485886 10.10.0.33.4449  10.100.0.20.1521: P 45:82(37) ack
  862 win
  64674 (DF)
  11:58:13.495067 10.10.0.85.3686  10.100.0.20.1521: P 229:274(45) ack
  1159 win
  65535 (DF)
  11:58:13.498905 10.10.20.200.3555  10.100.0.30.5900: . ack
  3093581142 win
  64760 (DF)
  11:58:13.499287 10.10.20.200.3555  10.100.0.30.5900: P 0:10(10) ack
  1 win
  64760 (DF)
  11:58:13.499671 10.10.0.37.4240  10.100.0.20.1521: P 163:347(184)
  ack 215 win
  65136 (DF)
  11:58:13.503325 10.10.0.33.4449  10.100.0.20.1521: P 82:864(782) ack
  931 win
  64605 (DF)
  11:58:13.509570 10.10.0.85.3686  10.100.0.20.1521: P 274:311(37) ack
  2020 win
  64674 (DF)
  11:58:13.511985 10.10.0.101.1362  10.100.0.4.5900: . ack 163 win
  65373 (DF)
  11:58:13.512286 10.10.0.32.1271  10.100.0.20.1521: P
  66502839:66503932(1093)
  ack 1747230381 win 64931 (DF)
  11:58:13.512293 10.10.0.101.1362  10.100.0.4.5900: P 10:20(10) ack
  163 win
  65373 (DF)

  Today i was not able to find who is fuck*** the mpls link.

  Can you help/teach me how to identify heavy users?

  Thanks

-
Fe din egen, gratis e-postadresse pe Start.no

Re: Dump on soekris slow?

[Simen Stavdal]

Hi Lars,

The USB 2.0 Specification says max 480Mbps, and is to be considered a
theroretical max.
This equates to about 60MBytes/second.

The devices that connect through the bus rarely get even close to this
rate.
In fact, if you compare it to the SATA-2 specification says 3000Mbps
(375MBytes/second, roughly 6 times faster than USB 2.0).
Disks on SATA-2 Controllers sometimes achieve as much as peak of 100MB/s
write performance which equates to about 800Mbps,
(and this is for rather fast disks, the average write speed is somewhere
around 65MBytes/second when directly connected to SATA-2).
This shows that the specification is a lot higher than the actual
throughput you get.

Your external disk is connected through a USB 2.0 Connector, and the disk
itself is connected through a controller (probably PATA or SATA) in the
disk housing.
There are many bottlenecks between your soekrisbox and the actual disk,
limiting the transfer rate quite a lot.

1. The soekrisbox itself, and it's USB 2.0 controller.
2. The Adaptor in the disk enclosure (from USB2.0 to SATA/PATA).
3. The disk itself (could be limited by a number of things, such as the
rotational speed of the disk etc).
4. Never believe marketing! They never show the real performance, only
the thoretical, not limited by all the bottlenecks.

I would say that your speed of 5,3MBytes/second, is not to far off what
to expect. You could obviously test this on another machine to find out
*where* the bottleneck is.
If you get substancially higher speeds, then you know it is the
controller in your soekrisbox...

Cheers,
Simon.

On Fri Nov 14 10:25 , Tom Van Looy sent:

  Is it slower than the USB is *supposed* to be? USB is not fast.

  The external disk is a:
  http://www.wdc.com/en/products/products.asp\?driveid=333
  It has:
  Serial Bus Transfer Rate (USB 2.0) 480 Mbits/s (Max)

  The soekris port is 2.0 capable usb0 at ehci0: USB revision 2.0.
  I'm getting an average transfer rate of 5350 KB/s.

  By the way, the internal disk is a:
  http://www.wdc.com/en/products/products.asp\?driveid=477

  Kind regards,

  Tom

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Ok,

Here are the first results
I have set up loopback addresses with the same ip address on two
receivers (for testing). (A.A.A.10)
Each receiver has unique external ip adresses in the same subnet as the
$nms_if

First, I created this rule :
pass in on $int_if dup-to ( $nms_if $nms_broadcastaddress ) proto udp
from 10.10.10.1 to $receiverloopbackaddress port 162
# I have tried to make the macros self-explanatory, so I won't include
their definitions here.
The rule gets accepted, and expands to :
pass in quick on bge1 dup-to (vlan4 A.A.A.15) inet proto udp from
10.10.10.1 to A.A.A.10 port = snmp-trap keep state
# The subnet is /28, hence the broadcast is .15 on network 0.

Although pf accepts the syntax, nothing happens when firing off a trap to
A.A.A.10.
If I replace $nms_broadcastaddress with one of the physical addresses
(f.ex A.A.A.1 or A.A.A.2) I can see the trap coming from 10.10.10.1 and
heading for A.A.A.10 on the receiver.

Since dup-to a broadcast address doesn't seem to work (unless I am doing
something completely wrong), I then need to specify multiple hosts, which
is not supported.
I can add a single address for the dup-to rule, but trying to add
multiple hosts gives me a syntax error when trying to load the conf
file.

I tried ( { $nms_if $nms-a, $nms_if $nms-b } ) but apparently this is not
supported (and syntax error is my bane).

So, I am sort of back to square one... broadcast not supported and
multiple individual receivers is not supported
BTW, Please correct me if anyone has been successful at this, because I
don't want to conclude on this unless it is correct.

That leaves me with multicast, which is yet to be tried, however, I don't
have much experience with this one, so testing may take  a little
longer...

Cheers,
Simon.

On Wed Nov 5 17:12 , Damian Gerow sent:

  Good luck, and let the list know how this fares out. I'm sure you're
  not
  the only person who's run into this problem before, and I'm curious
  to see
  what works out for your setup.

  As for submitting a feature request... TBH, I don't know. I'm not
  sure if
  sendbug is appropriate for feature requests or not. Given the text
  under
  http://www.openbsd.org/report.html, it sounds like sendbug is
  appropriate
  for feature requests, but you may want to double-check that yourself.

  - Damian

  Simen Stavdal wrote:
  :
  : Hello again,
  : Ok, I think we are getting closer to a resolution.
  : I like the loopback solution (never thought of that), it should
  work
  : for udp at least since it is connection-less, and it would work for
  my
  : scenario and netflow alike.
  : Then you could add multiple loopbacks to subscribe to different
  snmp
  : traps.
  : Tomorrow I will test this, and I will let you know how I got on.
  : If one were to request a new features from the OBSD developers, how
  : would one go about it?
  : Regarding whether or not it is the right tool to use, I agree,
  should
  : be up to the developers, but I thought it would be a natural place,
  : since it can be combined with a lot of other features,
  : such as carp for redundancy etc, ...TBC...
  : Russell and Damian also suggested sending traps as multicast, which
  I
  : will give a try too.
  : So long, and thanks for all the help so far !
  : Cheers,
  : Simon.
  : On Wed Nov 5 16:29 , Damian Gerow sent:
  :
  : Simen Stavdal wrote:
  : : Worth submitting a feature request?
  : : --- I looks like this would be the best solution ---
  : Sounds like you have your desired solution. So long as the OBSD
  : developers
  : accept your request as valid.
  : : --- The subject of my posting is Duplicating incoming packets to
  : : multiple destinations using pf ---
  : : --- And I never initially asked a closed question, but I did
  : state
  : : a scenario ---
  : Right, so I was led to believe that the context of your question
  : was limited
  : to re-mapping SNMP destinations. In other words, you had a specific
  : problem
  : on hand to solve, and that SNMP trap multiplexing was that problem.
  : : You have a piece of machinery. It's going to send traffic, to a
  : : given
  : : destination. However, this destination may be more than one
  : : machine. It
  : : may be two. It may be five. And the traffic may be single
  : : datagrams, or
  : : it may be a constant stream. Who knows. You don't want to update
  : : the
  : : source when this destination point changes, due to administrative
  : : overhead.
  : : So, you need an arbitrary resolution that is not
  : protocol-specific,
  : : that
  : : provides a single point of management (or otherwise incurs a very
  : : low
  : : administrative overhead), and where the client doesn't need to be
  : : modified.
  : : --- I wouldn't describe the scenario as arbitrary ---
  : Let's not argue over words.
  : You need a resolution that can be applied to any number of
  : situations. You
  : need a resolution that is sufficiently abstracted such that it
  : addresses
  : the root problem

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hello Damian/Claer/misc,

Thanks for your feedback,

Just a bit more background...
Here is some of my reasoning for wanting to do trap handling and
duplications
There are several advantages to having the devices send only one trap to
a central system.
1) Less configuration on the devices (and also less load, though not a
big problem anymore). This is not really a problem for small
installations, but once you have 500+ devices to configure, it is easy to
do the maths.
2) Easier to administer centrally by making profiles based on source
addresses etc.
3) Maintaining the source address in the trap udp header.

I have looked at trap exploders (my guess is that you are referring to
CA's trap exploder?), but a lot of these store and forward the traps,
thereby issuing new packets with a source address of the trap exploder.
Perhaps Claers idea of proxying with net-snmp is a way to do it (but I
have a feeling this might be store and forward too... I'll check it out
though.

Anyway, thanks for all the tips :)
Much appreciated,
Simon.

On Tue Nov 4 22:16 , Damian Gerow sent:

  Claer wrote:
  :  Thanks for the answer, I guess dup-to isn4t the right tool
  then...
  :  Has anyone tried to achieve what I am trying to do though?
  :  I am obviously open to other ideas.
  : Maybe I'll give you a wrong path but, did you looked at proxying
  the
  : trap with net-snmp ?
  : Direct the original trap to your firewall (carped ?) and then when
  the
  : trap arrives on it, ask net-snmp to send serveral traps to the
  : supervision servers.

  I can't help but feel that the OP is trying to use the wrong tool for
  the
  job. There are two really good options when dealing with what he's
  trying
  to do:

  1) Configure multiple SNMP trap destinations in the client. Any
  halfway
  decent SNMP stack supports trapping to more than one destination. But
  in
  the cases this doesn't work...

  2) Investigate a trap exploder. Heck, you could even run it right on
  the
  firewall itself, as Claer has suggested. (In fact, this is *exactly*
  what
  Claer suggested, only I've called it a fancy name: trap exploder.)

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hi Damian/misc,

I appreciate your input -I really do.
Please see my comments below.

Cheers,
Simon.

On Wed Nov 5 14:46 , Damian Gerow sent:

  Simen Stavdal wrote:
  : 1) Less configuration on the devices (and also less load, though
  not a
  : big problem anymore). This is not really a problem for small
  : installations, but once you have 500+ devices to configure, it is
  easy
  : to do the maths.

  You should always have systems in place to manage your installation.
  Larger
  installations require more effort in getting those systems in place.
  There
  are umpteen options available at your fingertips with little to no
  effort,
  and there's another umpteen products -- both free and paid -- that
  will help
  you do this as well.

  This should *never* be a reason for doing (or not doing, as the case
  may be)
  something. And I'm speaking as someone with experience handling large
  installations.

  I am not trying to escape the fact that one needs systems in place to
  manage large installations, I am merely looking for what *I* think
  would be a better way to deploy resources.
  As a service provider I can provide advice (and hence I posted this
  question in the first place to see if there was a good way to
  multicast traps to predefined destinations), but it is not in my
  power to manage a customers network - so this I'm afraid is out of my
  control - but I do agree with your point ...should *never* be a
  reason

  : 2) Easier to administer centrally by making profiles based on
  source
  : addresses etc.

  Um, sure? See above.

  If you have a good addressing/naming scheme, I believe so.

  : 3) Maintaining the source address in the trap udp header.
  : I have looked at trap exploders (my guess is that you are
  referring
  : to CA's trap exploder?), but a lot of these store and forward the
  : traps, thereby issuing new packets with a source address of the
  trap
  : exploder. Perhaps Claers idea of proxying with net-snmp is a way to
  do
  : it (but I have a feeling this might be store and forward too...
  I'll
  : check it out though.

  No, I wasn't explicitly referring to CA's Trap Exploder, or I would
  have
  capitalized it. It's just what we call them in my place of employ.

  I'll admit that the source issue is a valid one, and one we struggled
  with
  (with our internally developed trap exploder).

  Maybe this could be input for further development of pf? As one can
  think of many alternative workarounds, can one think of a reason not
  to implement this feature (technially or otherwise)?

  However, if you *really*
  want to maintain source address, I'd argue that the proper way to do
  it is
  have the source send multiple traps.

  I can think of other scenarios too, where this functionality might
  prove useful, for instance for netflow export which may produce a lot
  more output than snmp traps, and thereby adding load on the network.
  Preserving the source address is important to identify the source,
  and while you can do this in snmp traps, using the i-agent field, or
  a varbind, it may not be the case for other protocols.

  As a workaround, you can try to coax your trap exploder (or proxy or
  forwarder or whatever you want to call it) to add the original source
  IP as
  a varbind, and then configure your NMSs to replace the source with
  the
  contents of that varbind.

  (Alternatively, Net-SNMP can pass the trap on to an external script.
  From
  there, the possibilities are endless.)

  - Damian

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hi Damian,

Nothing like a fiery discussion :)

On Wed Nov 5 15:39 , Damian Gerow sent:

  Simen Stavdal wrote:
  : I am not trying to escape the fact that one needs systems in place
  : to manage large installations, I am merely looking for what *I*
  : think would be a better way to deploy resources.

  I'm just going to drop this part of the thread.

  : As a service provider I can provide advice (and hence I posted this
  : question in the first place to see if there was a good way to
  : multicast traps to predefined destinations), but it is not in my

  ... but I want to keep this in the message.

  : Maybe this could be input for further development of pf? As one can
  : think of many alternative workarounds, can one think of a reason
  : not to implement this feature (technially or otherwise)?

  Worth submitting a feature request?

  --- I looks like this would be the best solution ---

  : I can think of other scenarios too, where this functionality might
  : prove useful, for instance for netflow export which may produce a
  : lot more output than snmp traps, and thereby adding load on the
  : network. Preserving the source address is important to identify the
  : source, and while you can do this in snmp traps, using the i-agent
  : field, or a varbind, it may not be the case for other protocols.

  Now, we've changed the scope of the problem from SNMP to traffic.
  And
  you've already answered your own question.

  --- The subject of my posting is Duplicating incoming packets to
  multiple destinations using pf ---
  --- And I never initially asked a closed question, but I did state a
  scenario ---

  You have a piece of machinery. It's going to send traffic, to a given
  destination. However, this destination may be more than one
  machine. It
  may be two. It may be five. And the traffic may be single datagrams,
  or
  it may be a constant stream. Who knows. You don't want to update the
  source when this destination point changes, due to administrative
  overhead.

  So, you need an arbitrary resolution that is not protocol-specific,
  that
  provides a single point of management (or otherwise incurs a very low
  administrative overhead), and where the client doesn't need to be
  modified.

  --- I wouldn't describe the scenario as arbitrary ---
  --- There is a very usable syntax in place, which is also the beauty
  of pf ---
  --- For example, *if* what I am looking for had existed it would
  apply to any protocol ---
  --- Because it doesn't care about the payload, only the headers ---
  --- Since both Netflow and snmp traps use UDP, I don't see why it
  shouldn't work ---

  Remember way above when you mentioned the word multicast? There's
  absolutely no reason why your trap destinations couldn't be a
  multicast
  address. Same with your netflow destinations. Or, heck, your SMTP
  destinations, if you're feeling adventurous. Granted, this is a
  network
  re-architecture, but see below before responding.

  --- A multicast sends traps to all listening devices, which excludes
  the opportunity to ---
  --- filter destinations in pf ---

  There's two different discussions going on here, that are
  complicating
  things.

  1) You're looking for a short-term fix for your problem. You've been
  handed
  a short-term fix.

  --- I didn't say I was looking for a short term fix ---

  2) Because you don't like the short-term fix, the conversation has
  shifted
  to looking for a long-term fix (changes to pf, network
  re-architectures,
  etc.).

  --- Please see the subject of my message ---

  --- Now, I don't know the answer to what I am looking for, that is
  why I am asking ---

  Cheers,
  Simon.

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hi Russell,

Thanks for your answer.
Sending traps to multicast addresses seems like a good idea, except it
would be up to the receiver to decide whether to use the trap or not
(taking away the possibility to filter which hosts gets copied the traps
(multicast traps to predefined destinations)).

I not sure if this is going to be possible, but maybe tagging incoming
traps based on the source address combined with rule that anchors into a
new ruleset using rdr or something.
(Unless you didn't use strict order for rdr/nat before rules etc).

For example, I tried this (which didn't work)
rdr on $int_if proto udp from 10.10.10.10 to $nms-a port 162 - $nmstable
port 162
# Were $nmstable is nms-a,b,c etc
This will load, but expands to :
rdr on bge1 inet proto udp from 10.10.10.10 to x.x.x.x port = snmp-trap
- { x.x.x.x, y.y.y.y, z.z.z.z } port 162 round-robin

The keyword here is round-robin which is the only accepted argument
when using a host table.

I will give multicast a try, as it may be a better fix than store and
forward, replacing the source address.
Ultimately, I think this is a feature request.

Thank you,
Simen.

On Wed Nov 5 15:28 , Russell Howe sent:

  Simen Stavdal wrote, sometime around 05/11/08 14:14:
   Hi Damian/misc,
  
   I appreciate your input -I really do.
   Please see my comments below.
  
   I am not trying to escape the fact that one needs systems in place
  to
   manage large installations, I am merely looking for what *I* think
   would be a better way to deploy resources.
   As a service provider I can provide advice (and hence I posted this
   question in the first place to see if there was a good way to
   multicast traps to predefined destinations), but it is not in my
   power to manage a customers network - so this I'm afraid is out of
  my
   control - but I do agree with your point ...should *never* be a
   reason

  Maybe you answered your own question here - what if you sent your
  traps
  to a multicast address and had proper multicast routing?

  Not something I've ever tried, mind you...

  --
  Russell Howe, IT Manager. [EMAIL PROTECTED] mtmarinerisk.com
  BMT Marine  Offshore Surveys Ltd.

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hello again,

Ok, I think we are getting closer to a resolution.
I like the loopback solution (never thought of that), it should work for
udp at least since it is connection-less, and it would work for my
scenario and netflow alike.
Then you could add multiple loopbacks to subscribe to different snmp
traps.

Tomorrow I will test this, and I will let you know how I got on.
If one were to request a new features from the OBSD developers, how would
one go about it?

Regarding whether or not it is the right tool to use, I agree, should be
up to the developers, but I thought it would be a natural place, since it
can be combined with a lot of other features,
such as carp for redundancy etc, ...TBC...

Russell and Damian also suggested sending traps as multicast, which I
will give a try too.

So long, and thanks for all the help so far !

Cheers,
Simon.

On Wed Nov 5 16:29 , Damian Gerow sent:

  Simen Stavdal wrote:
  : Worth submitting a feature request?
  : --- I looks like this would be the best solution ---

  Sounds like you have your desired solution. So long as the OBSD
  developers
  accept your request as valid.

  : --- The subject of my posting is Duplicating incoming packets to
  : multiple destinations using pf ---
  : --- And I never initially asked a closed question, but I did state
  : a scenario ---

  Right, so I was led to believe that the context of your question was
  limited
  to re-mapping SNMP destinations. In other words, you had a specific
  problem
  on hand to solve, and that SNMP trap multiplexing was that problem.

  : You have a piece of machinery. It's going to send traffic, to a
  : given
  : destination. However, this destination may be more than one
  : machine. It
  : may be two. It may be five. And the traffic may be single
  : datagrams, or
  : it may be a constant stream. Who knows. You don't want to update
  : the
  : source when this destination point changes, due to administrative
  : overhead.
  : So, you need an arbitrary resolution that is not protocol-specific,
  : that
  : provides a single point of management (or otherwise incurs a very
  : low
  : administrative overhead), and where the client doesn't need to be
  : modified.
  : --- I wouldn't describe the scenario as arbitrary ---

  Let's not argue over words.

  You need a resolution that can be applied to any number of
  situations. You
  need a resolution that is sufficiently abstracted such that it
  addresses
  the root problem, not the specific use case you supplied.

  This is where I went wrong, and my apologies: I addressed the
  specific
  instance of the problem, and not the underlying challenge.

  : --- There is a very usable syntax in place, which is also the
  : beauty of pf ---

  Whether or not it's the right tool for the job, I leave it up to the
  OBSD
  developers to decide.

  : --- A multicast sends traps to all listening devices, which
  : excludes the opportunity to filter destinations in pf ---

  Not entirely true. A multicast packet is destined towards a single
  address,
  for which multiple (physically separate hosts) are listening. Network
  gear
  duplicates the packet as needed, to ensure it reaches all members of
  that
  multicast group.

  I'm arguing semantics here, but there's a very important distinction:
  your
  SNMP client only sends out *one* packet per trap.

  : things.
  : 1) You're looking for a short-term fix for your problem. You've
  : been handed
  : a short-term fix.
  : --- I didn't say I was looking for a short term fix ---

  Not explicitly, but you implied it with your use case. Or maybe I
  misread
  you. Either way, you've established that you don't care to fix this
  specific SNMP problem, you want PF to be modified to do what you
  need.

  (Speaking of which, there's Yet Another Alternative. Set your trap
  destination to be some arbitrary address. Assign that address to the
  loopback interface of *all* SNMP receivers. Assign unique IPs to
  their
  external interfaces. That way, when you use pf's dup-to, each machine
  will
  actually receive the packet. It's clean, uses the functionality that
  currently exists, is only a mild abuse of best practices, and
  requires no
  network reconfiguration. This approach can be duplicated as needed.)

  - Damian

-
FC% din egen, gratis e-postadresse pC% Start.no

Re: Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hi Giancarlo/misc,

Thanks for the answer, I guess dup-to isn4t the right tool then...
Has anyone tried to achieve what I am trying to do though?
I am obviously open to other ideas.

The main objective though, is to preserve the source address, while
replacing the destination address to multiple hosts

Cheers,
Simon.

On Nov 4, 2008, at 5:32 PM, Giancarlo Razzolini wrote:


Simen Stavdal escreveu:

Hello,

I have the following scenario.

A router (let's call it router A) is sending snmp traps to an nms
(Network Monitoring System).
Between the router A and the nms (let's call it nms-a) is a Dell
PowerEdge 860 running OpenBSD 4.1 i386 (bsd.mp) and pf.
On the same segment as nms-a, is nms-b, nms-c etc.

I am trying to make pf copy the incoming trap, while keeping the
source
ip address (of router A), and changing the destination ip for nms-
a,b,c
etc,
but I am not even sure if this is the right way about it.

This is a variant of the rule that I have tried :
pass in on $int_if dup-to ($nms_if $nms-b ) proto udp from
10.10.10.1 to
$nms-a port 162

(all macros are defined, and expanded correctly in the ruleset when
issuing pfctl -s all )

The way I have understood the syntax, is that traps destined for
nms-a,
will be duplicated to nms-b.
However, when I tcpdump the nms_if, I can only see traps for nms-a
(and
none for b).

I mentioned that the rule was a variant, because I have tried several
other options, but to no avail.
Has anyone done this before? Am I barking up the wrong tree?

Here is some more (hopefully) useful information :
tcpdump output (x.x.x.2 is the ip of nms-a, and Y.Y.Y.Y is the agent
address (the source ip of the trap))
12:21:04.798192 10.10.10.1.2074  X.X.X.2.snmp-trap: Trap(36)
E:cisco.9.41.2 [Y.Y.Y.Y] enterpriseSpecific[specific-trap(1)!=0]
16671316
.iso.org=[|snmp]

The expanded rule from pfctl -s all | grep dup-to
pass in on bge1 dup-to (vlan4 Z.Z.Z.1) inet proto udp from
10.10.10.1 to
X.X.X.2 port = snmp-trap keep state
(Z.Z.z.1 is nms-b)

Any input is very welcomed,

Cheers,
Simon Stavdal.

-
Fe din egen, gratis e-postadresse pe Start.no




As the man page states, it literally duplicate the packet. It means
that an exact copy of it will be sent to the specified machine.
Also, you are not seeing them when you use tcpdump, because they are
all the same. If nms-b isn't prepared to receive an packet which
wasn't destined for it, it will discard the packet silently. You
must check on nms-b if it is receiving the packets.

My regards,

--
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85

Duplicate incoming packets to multiple destinations using pf

[Simen Stavdal]

Hello,

I have the following scenario.

A router (let's call it router A) is sending snmp traps to an nms
(Network Monitoring System).
Between the router A and the nms (let's call it nms-a) is a Dell
PowerEdge 860 running OpenBSD 4.1 i386 (bsd.mp) and pf.
On the same segment as nms-a, is nms-b, nms-c etc.

I am trying to make pf copy the incoming trap, while keeping the source
ip address (of router A), and changing the destination ip for nms-a,b,c
etc,
but I am not even sure if this is the right way about it.

This is a variant of the rule that I have tried :
pass in on $int_if dup-to ($nms_if $nms-b ) proto udp from 10.10.10.1 to
$nms-a port 162

(all macros are defined, and expanded correctly in the ruleset when
issuing pfctl -s all )

The way I have understood the syntax, is that traps destined for nms-a,
will be duplicated to nms-b.
However, when I tcpdump the nms_if, I can only see traps for nms-a (and
none for b).

I mentioned that the rule was a variant, because I have tried several
other options, but to no avail.
Has anyone done this before? Am I barking up the wrong tree?

Here is some more (hopefully) useful information :
tcpdump output (x.x.x.2 is the ip of nms-a, and Y.Y.Y.Y is the agent
address (the source ip of the trap))
12:21:04.798192 10.10.10.1.2074  X.X.X.2.snmp-trap: Trap(36)
E:cisco.9.41.2 [Y.Y.Y.Y] enterpriseSpecific[specific-trap(1)!=0] 16671316
.iso.org=[|snmp]

The expanded rule from pfctl -s all | grep dup-to
pass in on bge1 dup-to (vlan4 Z.Z.Z.1) inet proto udp from 10.10.10.1 to
X.X.X.2 port = snmp-trap keep state
(Z.Z.z.1 is nms-b)

Any input is very welcomed,

Cheers,
Simon Stavdal.

-
Fe din egen, gratis e-postadresse pe Start.no