Hi Steve,
Thanks for your reply! I read your thread before I posted this, but since it
applied to a transparent bridge it was a bit hard for me to see if the
solutions applied to my problem.
However, I just fixed my problem by adding a route-to in the firewall rule,
which routes the packet over to the internal interface ($int_if):
FROM:
>> 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
to:
pass in log on {$ext_if $int_if} route-to $int_if proto udp from
external.sip.proxy.example port sip to internal.sip.proxy.test port 6060 tag
VoIP2 keep state
I now see that Mark Pecaut actually wrote the answer for me in his reply to
you, except that I'm routing to $int_if and not lo0.
Best regards,
Andreas
>-----Original Message-----
>From: Steve Williams [mailto:[EMAIL PROTECTED]
>Sent: 9. mai 2007 17:09
>To: Andreas Hdber
>Cc: misc@openbsd.org
>Subject: Re: Redirected packet from pf is lost
>
>Andreas Hdber wrote:
>> 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
>>
>Hi,
>
>Check out a (very) recent thread initiated by myself with the
>subject "rdr on bridge interface possible? (squid transparent
>proxy on bridge)".
>
>There are a few suggestions there, none of which have worked
>for me. I have no idea why it's not working for me.
>
>Let me know if you get it working!
>
>Cheers,
>Steve Williams
