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:
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 <umop apisdn> from up over?
