isakmpd och routing/NAT....

Leif Larsson leif.larsson at l3system.se
Mon Oct 26 14:15:45 CET 2009


Ur mansidan (ipsec.conf):

For example, if the local subnet is 192.168.1.0/24 and all the traffic
for a specific VPN peer should appear as coming from 10.10.10.1, the fol
lowing configuration is used:

ike esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 \
                   peer 10.10.20.1

Naturally, a relevant NAT rule is required in pf.conf(5).  For the
example above, this would be:

nat on enc0 from 192.168.1.0/24 to 192.168.2.0/24 -> 10.10.10.1

>From the peer's point of view, the local end of the VPN tunnel is de
 clared to be 10.10.10.1 and all the traffic arrives with that source ad
    dress.


Anders Troback wrote:
> Hm, OK, vet inte om helgen tog hårt på hjärnan men jag fattar inte
> riktigt det där just nu:-] Ska det vara i 1.2.3.4 eller i klientens
> ipsec.conf som jag ska sätta min påhittade adress?
> 
> Routeen kan jag ju bara sätta statisk i min default gw!
> 
> Ingen stor nackdel precis!
> 
> 
> \\anders
> 
> Den Mon, 26 Oct 2009 13:50:53 +0100
> skrev Leif Larsson <leif.larsson at l3system.se>:
> 
>> Har du kollat på "srcnat" parametern i "from" sektionen ?
>> from src [port sport] [(srcnat)] to dst [port dport]
>>
>> Det borde lösa dina problem. Någon form av route tillbaka till 1.2.3.4
>> måste du nog ändå ha.
>>
>> Nackdelen med srcnat är att du inte kommer åt deras "hemmanät" (utan
>> en massa pf-trixande), men det är säkert ok.
>>
>> Lite OT, för "road warriors" tycker jag OpenVPN fungerar fantastiskt
>> bra, "plattformsoberoende",  samma konf på alla klienter. "Central"
>> administration, Cert eller lösenord. "VPN-DHCP", knappt några
>> MTU-issues, etc etc etc.
>>
>> /Leif
>>
>> Anders Troback wrote:
>>> Hej,
>>>
>>> nu är det dax att terrorisera er lite igen:-)
>>>
>>> För den som missat det tidigare i listan så har jag brottats lite
>>> med ipsec och löste det mesta med hjälp av OpenBSD's isakmpd och
>>> tunnlarna funkar jätte bra, men...jag har ett litet problem med att
>>> få trafiken att flöda på ett smart sätt pga. routing. Ska försöka
>>> förklara!
>>>
>>> Jag har ett nät som ska nås utifrån av personal som ska kunna jobba
>>> från sitt hem. Nätet de ska nå är 10.1.0.0/17 och de gör de via en
>>> OpenBSD burk som har IP 1.2.3.4. Tanken är sedan att användarana
>>> startar en OpenBSD burk hemma och kopplar upp sig. Det som gör att
>>> jag får lite problem är att jag inte vet vilket nät de kommer ifrån
>>> och jag vill inte behöva tänka på det heller så att de är fria att
>>> ta med sig sin OpenBSD vart de än vill åka plus att jag inte vill
>>> administrera deras hemma nät!
>>>
>>> 1.2.3.4 sitter "sidan om" brändväggen som även är default gw till
>>> 10.1.0.0/17 nätet. För att kunna förklara så utgår jag från att
>>> användaren kopplar upp sig från 192.168.0.1 bakom en NAT:ad
>>> brändvägg!
>>>
>>> Så till själva problemet, när man kopplar upp sig och skickar en
>>> tex. en ping till 10.1.0.1 så kommer begäran fram till målet men
>>> eftersom 10.1.0.1 inte känner till 192.168.0.1 så den skickar det
>>> till default gw som försöker skicka ut det på Internet! Visst jag
>>> kan sätta en statisk route till 192.168.0.0/24 i min gw men jag vet
>>> ju inte att de alltid kommer från 192.168.0.0, de man ju komma från
>>> en svart adress eller från ett helt annat när som tex. 172.16.0.0
>>> eller så!
>>>
>>> Min ipsec.conf på 1.2.3.4 ser ut så här (nästan iaf;-)):
>>>
>>> ike passive esp from 10.1.0.0/17 to any srcid vpn.bus.org
>>>
>>> Och på mina klienter har en ipsec.conf som ser ut så här:
>>>
>>> ike esp from egress to 10.1.0.0/17 peer 1.2.3.4 \
>>>         srcid anders at bus.org dstid vpn.bus.org
>>>
>>> Känns inte som om jag är den enda som har problemet så det är nog
>>> bara jag som missat någon! Tacksam för alla tips och råd!
>>>
>>>
>>> Mvh,
>>> Anders Trobäck
>>>
>> _________________________________________________
>> BSD Users Sweden -- BUS at stacken.kth.se
>> https://lists.stacken.kth.se/mailman/listinfo/bus
>>
> 


More information about the BUS mailing list