For what its worth: I have setup an exact same Machine at Home, same Network
Topology etc, and it works just fine.

What is different at work is that we have a switch in between that also
routing, i assume the problem lies there.

regards and a nice day,
D

On May 18, 2011, at 10:18 PM, David Schulz wrote:

> Well for once i thought the Route is listed there already:
>
> Default Gateway:
>> default            10.1.3.1           UGS        0        3     -     8
> sis0
>
> And everything to the 192. Subnet out via sis1
>> 192.168.1/24       link#2             UC         1        0     -     4
> sis1
>
>
>
> So i have to add something else? One Side of the Network is 10.1.0.0/21
with
> Gateway 10.1.3.1, so i add
>        route add -net 10.1.0.0/21 10.1.3.1
>
> The other Side, for which the OpenBSD Box is the Gateway is 192.168.1.0/24,
so
> i suppose i add
>       route add -net 192.168.1.0/24 192.168.1.1 ?
>
> Thanks for your insights.
>
>
> On May 18, 2011, at 10:06 PM, R0me0 *** wrote:
>
>> Put a route !?
>>
>> 2011/5/18 David Schulz <mailingli...@ironwhale.com>
>> Hi there,
>>
>> if i disable pf, it will not work (except when trying from router itself
> via
>> ssh). Here some output from hostname.ifs and mygate, my routing table.
> Would
>> be most grateful for any tips that help solving this.
>>
>> Best regards,
>> D
>>
>> cndlne001'root(~)> cat /etc/hostname.sis0
>> inet 10.1.3.19 255.255.254.0 NONE
>> cndlne001'root(~)> cat /etc/hostname.sis1
>> inet 192.168.1.1 255.255.255.0 NONE
>> cndlne001'root(~)> cat /etc/mygate
>> 10.1.3.1
>> cndlne001'root(~)> route -n show
>> Routing tables
>>
>> Internet:
>> Destination        Gateway            Flags   Refs      Use   Mtu  Prio
> Iface
>> default            10.1.3.1           UGS        0        3     -     8
> sis0
>> 10.1.2/23          link#1             UC         4        0     -     4
> sis0
>> 10.1.3.1           00:18:4d:33:e3:df  UHLc       1        0     -     4
> sis0
>> 10.1.3.7           f4:ce:46:b1:a6:26  UHLc       1       10     -     4
> sis0
>> 10.1.3.37          20:cf:30:56:15:80  UHLc       1      107     -     4
> sis0
>> 10.1.3.46          1c:af:f7:0e:17:20  UHLc       0       41     -     4
> sis0
>> 127/8              127.0.0.1          UGRS       0        0 33200     8
lo0
>> 127.0.0.1          127.0.0.1          UH         1        0 33200     4
lo0
>>
>
>> 192.168.1.2        00:14:97:02:2b:b2  UHLc       0       41     -     4
> sis1
>> 224/4              127.0.0.1          URS        0        0 33200     8
lo0
>>
>> cndlne001'root(~)> sysctl net.inet.ip.forwarding
>> net.inet.ip.forwarding=1
>>
>> sis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>       lladdr 00:00:24:ca:a9:f4
>>       priority: 0
>>       groups: egress
>>       media: Ethernet autoselect (100baseTX full-duplex)
>>       status: active
>>       inet 10.1.3.19 netmask 0xfffffe00 broadcast 10.1.3.255
>>       inet6 fe80::200:24ff:feca:a9f4%sis0 prefixlen 64 scopeid 0x1
>> cndlne001'root(~)> ifconfig sis1
>> sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>>       lladdr 00:00:24:ca:a9:f5
>>       priority: 0
>>       media: Ethernet autoselect (100baseTX full-duplex)
>>       status: active
>>       inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
>>       inet6 fe80::200:24ff:feca:a9f5%sis1 prefixlen 64 scopeid 0x2
>> cndlne001'root(~)>
>>
>>
>> On May 18, 2011, at 2:29 PM, Aaron Mason wrote:
>>
>>> If you've disabled pf and it doesn't, then yes, possibly.
>>>
>>> If the network is configured like this:
>>>
>>> 192.168.1.0/24]----192.168.1.1(em0)[Router]10.1.0.1(em1)----[10.1.0.0/21
>>>
>>> Setting the default routes to the required interface on each side
>>> should allow packets to flow freely from end to end.  There should be
>>> no need for PF trickery unless you wish to restrict access to certain
>>> machines on either side.
>>>
>>> Your best test is a traceroute.  Perform a traceroute from one side to
>>> the other, and see what the last step is before you get a string of
>>> timeouts.
>>>
>>> All said, I see rules in your PF that allow certain ICMP types, but
>>> haven't included the echo response - that's probably why you can't
>>> ping across the router.
>>>
>>> On Wed, May 18, 2011 at 3:29 PM, David Schulz
>>> <mailingli...@ironwhale.com> wrote:
>>>> Basically i am just trying to verify whether i actually do need the
> match
>>> out
>>>> statements in pf.conf in order for both Sides on each Network Cards to
>> talk
>>> to
>>>> each other. Say i do not, and it should all just work, does the fact
> that
>>> it
>>>> does not work suggest that i most likely have a routing issue?
>>>>
>>>> best regards,
>>>> D
>>>>
>>>> On May 17, 2011, at 9:29 PM, David Gwynne wrote:
>>>>
>>>>> hey david,
>>>>>
>>>>> pf is run twice on packets going through a box, once before the network
>>>> stack
>>>>> and again as it leaves it. this means you have to allow a packet in one
>>>> side
>>>>> as well as when it goes out the other.
>>>>>
>>>>> dlg
>>>>>
>>>>> On 17/05/2011, at 10:16 PM, David Schulz wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> i have a LAN within a LAN and the setup is as follows:
>>>>>>
>>>>>> 192.168.1.0/24 <-- OpenBSD 4.9 Router with 2 NICS --> 10.1.0.0/21
>>>>>>
>>>>>> My goal is to get both Sides talking to each other (lets start with
>>> making
>>>>>> them be able to ping each other). I got it working by using the
>> following
>>>>>> pf.conf, however i thought i should not need to have those match out
>>>>>> statements, because OpenBSD routes packets between interfaces by
> default
>>>> as
>>>>>> long sysctl net.inet.ip.forwarding=1 is set.
>>>>>>
>>>>>> From inside my OpenBSD Box i can ping Devices on either Side just
> fine.
>>>> From
>>>>> a
>>>>>> machine sitting on either Side, i can ping the OpenBSD Box just fine.
>> But
>>>> i
>>>>>> simply cannot get Side A Machines to talk to Side B Machines unless i
>>>>>> uncomment the two below match out statements inside my pf.conf.
>>>>>>
>>>>>> If someone could share some insight, id be most thankful.
>>>>>>
>>>>>> regards,
>>>>>> D
>>>>>>
>>>>>> Here my simplified pf.conf which again does not work unless i
> uncomment
>>>> the
>>>>>> two match out Rules:
>>>>>> ++++++++ pf.conf
>>>>>> int_if="sis0"
>>>>>> ext_if="sis1"
>>>>>>
>>>>>> icmp_types = "{ echoreq, unreach }"
>>>>>>
>>>>>> set require-order yes
>>>>>> set block-policy return
>>>>>> set optimization normal
>>>>>> set loginterface $ext_if
>>>>>>
>>>>>> match in all scrub (no-df)
>>>>>>
>>>>>> set skip on lo
>>>>>>
>>>>>> #match out on $int_if from 192.168.1.0/24 to any nat-to ($int_if)
>>>>>> #match out on $ext_if from 10.1.0.0/21 to any nat-to ($ext_if)
>>>>>>
>>>>>> block log all
>>>>>>
>>>>>> #Simplified for 'making it work purposes'
>>>>>> pass out quick
>>>>>> pass in quick
>>>>>>
>>>>>> antispoof quick for { lo0 $int_if $ext_if } inet
>>>>>>
>>>>>> # allow ICMP
>>>>>> pass in quick on { $int_if $ext_if } inet proto icmp all icmp-type
>>>>> $icmp_types
>>>>>> keep state
>>>>>> ++++++++
>>>>>>
>>>>>> ++++++++ route -n
>>>>>> cndlne001'root(~)> route -n show | grep default
>>>>>> default            10.1.3.1           UGS        0    23106     -
> 8
>>>>> sis0
>>>>>>
>>>>>> cndlne001'root(~)> route -n show | grep 192.168.1
>>>>>> 192.168.1/24       link#2             UC         2        0     -
> 4
>>>>> sis1
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Aaron Mason - Programmer, open source addict
>>> I've taken my software vows - for beta or for worse

Reply via email to