Hi all,

I've got a Dell SC1435, running OpenBSD 4.0, with two Ethernet interfaces
(bge0 and bge1) working as a gateway and firewall for our internal network.

bge0 is the external connection (with a class B IPv4 address), and bge1 is
the internal connection (private IP network, class C). They are both part of
a bridge, bridge0:
# cat /etc/bridgename.bridge0
add bge0
add bge1
blocknonip bge0
blocknonip bge1
up
#

Our pf-config has worked fine for normal Internet access, so internal
computers can access external hosts fine (through NAT).

However, now we need to redirect packets from an external host
("external.sip.proxy.example" below, using a normal class B IPv4 address) to
one of our internal hosts ("internal.sip.proxy.test" below, which is part of
the same private network as bge1 on our gateway). This is the first rdr rule
below. I've also used "rdr pass" instead of the explicit pass as shown
below, obviously with no success.

The pf-config looks like this (rules related to IPSec, SSH-access are
removed):
ext_if="bge0"                           # External interface
int_if="bge1"                           # Internal interface

set block-policy return
set loginterface $ext_if

set skip on { lo enc0 }

scrub in

rdr on $ext_if proto udp from external.sip.proxy.example port sip to any
port 6060 \
    tag VoIP -> internal.sip.proxy.test port 6060

nat on $ext_if from !($ext_if) to any -> ($ext_if)

nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021

block in log all

pass out keep state

anchor "ftp-proxy/*"
antispoof quick for { lo enc0 $int_if }

# Does NOT work (see tag on rdr-rule above)
pass in log tagged VoIP
# Does work, according to pflog. Tag is nowhere to be seen, though.
pass in log on {$ext_if $int_if} proto udp from external.sip.proxy.example
port sip to internal.sip.proxy.test port 6060 tag VoIP2 keep state

pass quick on { $int_if, enc0 }




# -- end pf.conf --


As you can see above, I'm logging blocked packets and also the relevant
packets passed in. I've found these two packets in pflog0 related to this.
The first one is a SIP request sent out from internal.sip.proxy.test to
external.sip.proxy.example:

Frame 205258 (1458 bytes on wire, 1458 bytes captured)
    Arrival Time: May  8, 2007 16:58:45.715379000
    [Time delta from previous packet: 679.119839000 seconds]
    [Time since reference or first frame: 8590.343581000 seconds]
    Frame Number: 205258
    Packet Length: 1458 bytes
    Capture Length: 1458 bytes
    [Frame is marked: True]
    [Protocols in frame: pflog:ip:udp:sip:sdp]
PF Log IPv4 passed on bge1 by rule 46
    Header Length: 61
    Address Family: IPv4 (2)
    Action: passed (0)
    Reason: match (0)
    Interface: bge1
    Ruleset:
    Rule Number: 46
    Sub Rule Number: -1
    Direction: Unknown (255)
Internet Protocol, Src: internal.sip.proxy.test (192.168.1.7), Dst:
external.sip.proxy.example (external.sip.proxy.example)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
        0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 1394
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (0x11)
    Header checksum: 0x622c [correct]
        [Good: True]
        [Bad : False]
    Source: internal.sip.proxy.test (192.168.1.7)
    Destination: external.sip.proxy.example (external.sip.proxy.example)
User Datagram Protocol, Src Port: 6060 (6060), Dst Port: 5060 (5060)
    Source port: 6060 (6060)
    Destination port: 5060 (5060)
    Length: 1374
    Checksum: 0x1eac [correct]
Session Initiation Protocol
    Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0
        Method: INVITE
        [Resent Packet: False]
[Snipped away rest of the SIP-content!]


The external.sip.proxy.example sends the following response back
Frame 205259 (805 bytes on wire, 805 bytes captured)
    Arrival Time: May  8, 2007 16:58:45.716547000
    [Time delta from previous packet: 0.001168000 seconds]
    [Time since reference or first frame: 8590.344749000 seconds]
    Frame Number: 205259
    Packet Length: 805 bytes
    Capture Length: 805 bytes
    [Frame is marked: True]
    [Protocols in frame: pflog:ip:udp:sip]
PF Log IPv4 passed on bge0 by rule 14
    Header Length: 61
    Address Family: IPv4 (2)
    Action: passed (0)
    Reason: match (0)
    Interface: bge0
    Ruleset:
    Rule Number: 14
    Sub Rule Number: -1
    Direction: Unknown (255)
Internet Protocol, Src: external.sip.proxy.example
(external.sip.proxy.example), Dst: internal.sip.proxy.test (192.168.1.7)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00)
        0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 741
    Identification: 0x0000 (0)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 63
    Protocol: UDP (0x11)
    Header checksum: 0x65b9 [correct]
        [Good: True]
        [Bad : False]
    Source: external.sip.proxy.example (external.sip.proxy.example)
    Destination: internal.sip.proxy.test (192.168.1.7)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 6060 (6060)
    Source port: 5060 (5060)
    Destination port: 6060 (6060)
    Length: 721
    Checksum: 0xbc55 [correct]
Session Initiation Protocol
    Status-Line: SIP/2.0 300 Redirect
        Status-Code: 300
        [Resent Packet: False]
[Rest of SIP-content is snipped away...]


As can be seen in the frame just above (Frame 205259), pf passes the frame
on by the pass-in rule from above (rule number 14 because some rules related
to IPSec & SSH-access has been removed). So, my question is sipmly where
will this packet end up now?

I'm also logging traffic at bge0, bge1 and bridge0, in addition to pflog0. I
see these packets on bge0 as well, before the rdr-rule has come into effect.
Also expected to see the response-packet on bge1 but, alas, that's nowhere
to be seen.

Thanks for any insight to help me solve this issue!

Best regards,
Andreas Hdber

Reply via email to