Hi RW
  I found the problem :-) My OpenVPN setup is OK. My ipsecctl.conf

was almost perfect: I setup the flow from my OpenBSD box (the branch

office) to be passive ... duh!!! ;-) Now that it has been converted

to dynamic the tunnel gets setup if the OpenVPN client initiates

traffic :-)
TIA

Paolo
RW wrote:
>On Mon, 03 Sep 2007 20:26:14 -0400, Paolo Supino wrote:

quoted text
>

>

>

>>Hi RW

>>

>> Except for the branch VPN to the main office subnet (line# 3) I have

>>the other IPSEC rules: peer to peer, 2 subnets to 1 subnet (and vice

>>versa on the main office VPN peer). Why do I need to setup a tunnel

>>between the branch firewall and main office subnet?

>>

>>

>>

>>

>>TIA

>>Paolo

>>

>>

>>RW wrote:

>>

>>

>>

>>>On Mon, 03 Sep 2007 17:15:02 -0400, Paolo Supino wrote:

>>>

>>>

>>>

>>>

>>>

>>>>Hi

>>>>

>>>>I have a firewall that also acts as a VPN peer for 2 VPNs. One of

>>>>the VPNs is IPSEC that connects between the main office and a branch

>>>>office. The second VPN is OpenVPN that connects windows based road

>>>>warriors to the branch office. I want to enable employees that connect

>>>>to the branch's OpenVPN to reach the main office servers (and filter

>>>>traffic to). Both VPNs are working so the appropriate routing entries

>>>>exist in the  firewall's routing table. Even if I disable all the

>>>>firewall rules and just let everything pass through the firewall the

>>>>OpenVPN clients still cannot reach the main office servers. What am

>>>>I missing?

>>>>

>>>>

>>>>

>>>>

>>>I'll bet you don't have some flows set up in ipsec.conf to handle it.

>>>Here is a simple ipsec.conf from one end of an ipsec tunnel where

>>>OpenVPN clients also login:

>>>ike esp from 10.10.8.0/24 to 172.22.3.0/24 peer 250.101.222.1

>>>ike esp from 172.22.2.0/24 to 172.22.3.0/24 peer 250.101.222.1

>>>ike esp from 195.228.107.202 to 172.22.3.0/24 peer 250.101.222.1

>>>ike esp from 195.228.107.202 to 250.101.222.1

>>>

>>>The first line adds the OpenVPN network to the mix.

>>>

>>>Needless to say the other end of the tunnel has an ipsec.conf that

>>>makes sure that traffic can return.

>>>

>>>Fictional addresses used to protect the innocent...

>>>

>>>Does that help?

>>>Please reply to the list. I am subscribed and don't need a cc, thanks.

>>>

>>>Rod/

>>>

>>>

>

>I don't know your setup because you didn't explain it fully but what I

>showed you works for my client.

>

>Let's make a symbolic ipsec.conf out of what I have shown you:

>ike esp from $OpenVPNlan to $HOlan peer $HOfirewall

>ike esp from $Branchlan to $HOlan peer $HOfirewall

>ike esp from $BranchFW to $HOlan peer $HOfirewall

>ike esp from $BranchFW to $HOfirewall

>You cannot use macros like that but perhaps it makes it clearer.

>

>In our case we have servers on both office LANs and the roadies using

>OpenVPN need to be able to get to both.

>

>You will have to trim and tweak your rules to suit your own variation

>but think about this.

>

>Regular route table entries have no influence on what happens with

>IPsec and do not need to.

>IPsec configuration sets up flows and then the packets "know" how to

>get to their target.

>If they don't have a flow path, they won't "know" how and will be

>routed out to the cloud via the default gateway and then get lost.

>

>Rod/

>

>Hint. Read this:

>A: Because it messes up the order in which people normally read text.

>Q: Why is top-posting such a bad thing?

>A: Top-posting.

>Q: What is the most annoying thing in e-mail?

>

>

>Rod/

>>From the land "down under": Australia.

>Do we look  from up over?