[IPSec] Firewall rules

Voor zover ik weet is dat met ipsec niet mogelijk. Dan zou je over moeten naar PPTP. IPSec pakt namelijk je hele pakketje in(inclusief source en destination adres) en als je dat door een NAT firewall heen haalt gaat het helemaal fout, omdat deze niet in het ipsec pakketje kijkt, maar er gewoon vanuit gaat dat het source en destination adres niet gecodeert zijn.

Correct me if I'm wrong

maandag 25 maart 2002 16:05

Acties:

Verwijderd

Topicstarter

Op maandag 25 maart 2002 15:55 schreef hightower het volgende:
Voor zover ik weet is dat met ipsec niet mogelijk. Dan zou je over moeten naar PPTP. IPSec pakt namelijk je hele pakketje in(inclusief source en destination adres) en als je dat door een NAT firewall heen haalt gaat het helemaal fout, omdat deze niet in het ipsec pakketje kijkt, maar er gewoon vanuit gaat dat het source en destination adres niet gecodeert zijn.

Correct me if I'm wrong

Het kan wel... alleen niet met AH met ESP kan het wel

maandag 25 maart 2002 16:08

Acties:

Verwijderd

Topicstarter

Oja deze rules heb ik nu

In ipf.rules

code:

# IPSec
pass in on tun0 proto 50 from any to any
pass in on xl0 proto 50 from any to any
# pass in on tun0 proto udp from any to any port = 1701
pass in on tun0 proto udp from any to any port = 500

In ipnat.rules

code:

map tun0 192.168.1.0/24 -> 0.0.0.0/32 portmap tcp/udp 40000:65000
map tun0 192.168.1.0/24 -> 0.0.0.0/32

#rdr tun0 0/0 port 1701 -> 192.168.1.100 port 1701
rdr tun0 0/0 port 0 -> 192.168.1.100 port 0 esp
rdr tun0 0/0 port 500 -> 192.168.1.100 port 500

maandag 25 maart 2002 16:10

Acties:

Op maandag 25 maart 2002 15:55 schreef hightower het volgende:
Voor zover ik weet is dat met ipsec niet mogelijk. Dan zou je over moeten naar PPTP. IPSec pakt namelijk je hele pakketje in(inclusief source en destination adres) en als je dat door een NAT firewall heen haalt gaat het helemaal fout, omdat deze niet in het ipsec pakketje kijkt, maar er gewoon vanuit gaat dat het source en destination adres niet gecodeert zijn.

Correct me if I'm wrong

Dat is niet helemaal juist, bij IPSec wordt wel het hele pakket gecodeerd maar de source en destination adres moeten er in blijven staan...

Als dit namelijk niet het geval is dan weten de routers tussen de comps niet waar de pakketjes heen moeten...

donderdag 28 maart 2002 10:14

Acties:

Verwijderd

Topicstarter

Heeft echt niemand IPSec door een firewall?

donderdag 28 maart 2002 11:38

Acties:

Op maandag 25 maart 2002 16:05 schreef quinty het volgende:

[..]

Het kan wel... alleen niet met AH met ESP kan het wel

AH ????? ESP???? leg eens uit

donderdag 28 maart 2002 15:00

Acties:

Op donderdag 28 maart 2002 11:38 schreef hightower het volgende:

[..]

AH ????? ESP???? leg eens uit

ESP is een protocol (net als TCP of UDP) alleen nu gaat alles gecodeerd...
AH betekend Authentication Header...

donderdag 28 maart 2002 15:08

Acties:

Verwijderd

Topicstarter

Op donderdag 28 maart 2002 15:00 schreef Birk het volgende:

[..]

ESP is een protocol (net als TCP of UDP) alleen nu gaat alles gecodeerd...
AH betekend Authentication Header...

En als de header gecodeerd is zoals bij AH, kan NAT hier niet mee om gaan

donderdag 28 maart 2002 17:27

Acties:

Verwijderd

Kun je niet freebsd als vpn gateway configen?

donderdag 28 maart 2002 21:24

Acties:

Op donderdag 28 maart 2002 15:08 schreef quinty het volgende:

[..]

En als de header gecodeerd is zoals bij AH, kan NAT hier niet mee om gaan

thnx, weer wat geleerd

kan ik ook weer verder prutsen

donderdag 28 maart 2002 22:06

Acties:

Jochem

IPSEC kan inderdaad niet altijd door een firewall aangezien de source en destination wordt gechecked of deze kloppen. Als deze door een firewall wordt gemangeld dat worden deze pakketten gedropped door de ontvanger. Ik weet niet zeker of het voor beide geld (AH en ESP) maar daar ben ik zo achter aangezien ik er momenteel mee bezig ben om het uit te zoeken.

om over de Authentication Header (AH) en Encapsulated Security Payload (ESP) protocol wat uit te wijden:
http://vpn.shmoo.com/vpn/FAQ.html

How does IPsec work with network address translation (NAT)?

NAT is incompatible with Authentication Header protocol, whether used in transport or tunnel mode. An IPsec VPN using AH protocol digitally signs the outbound packet, both data payload and headers, with a hash value appended to the packet. When using AH protocol, packet contents (the data payload) are not encrypted.

Why this bothers NAT is the last part: a NAT device in between the IPsec endpoints will rewrite either the source or destination address with one of its own choosing. The VPN device at the receiving end will verify the integrity of the incoming packet by computing its own hash value, and will complain that the hash value appended to the received packet doesn't match. The VPN device at the receiving end doesn't know about the NAT in the middle, so it assumes that the data has been altered for nefarious purposes.

IPsec using Encapsulating Security Payload in tunnel mode encapsulates the entire original packet (including headers) in a new IP packet. The new IP packet's source address is the outbound address of the sending VPN gateway, and its destination address is the inbound address of the VPN device at the receiving end. When using ESP protocol with authentication, the packet contents (in this case, the entire original packet) are encrypted. The encrypted contents, but not the new headers, are signed with a hash value appended to the packet.

This mode (tunnel mode ESP with authentication) is compatible with NAT, because integrity checks are performed over the combination of the "original header plus original payload," which is unchanged by a NAT device. Transport mode ESP with authentication is also compatible with NAT, but is not often used by itself. Since the hash is computed only over the original payload, original headers may be rewriten.

In addition, NAT may interfere with IPSec (both ESP and AH) if it prevents the two VPN gateways from successfully negotiating SAs using ISAKMP/IKE with certificates. X.509 certificates are signed by a trusted third party (called a Certificate Authority) in order to bind a user's or device's public key to some other identifying public characteristic. Once common identifying characteristic used for VPN gateway devices is external IP address.

vrijdag 12 april 2002 20:14

Acties:

Zo, ff topic omhoog schoppen

Iemand al meer informatie? Ik word er echt helemaal gek van.

Ik heb wel eens dat ik het probeer en dan zegt ie dat het certificaat ongeldig is. En de tweede keer zegt ie There is no answer. Wel vreemt.

woensdag 17 april 2002 16:48

Acties:

Op vrijdag 12 april 2002 20:14 schreef hightower het volgende:
Zo, ff topic omhoog schoppen

Iemand al meer informatie? Ik word er echt helemaal gek van.

Ik heb wel eens dat ik het probeer en dan zegt ie dat het certificaat ongeldig is. En de tweede keer zegt ie There is no answer. Wel vreemt.

ESP, AH en IKE door de firewall heen laten gaan...

donderdag 18 april 2002 12:55

Acties:

Op woensdag 17 april 2002 16:48 schreef Birk het volgende:

[..]

ESP, AH en IKE door de firewall heen laten gaan...

Op welke manier??? ik gebruik iptables

donderdag 18 april 2002 13:24

Acties:

Op donderdag 18 april 2002 12:55 schreef hightower het volgende:
Op welke manier??? ik gebruik iptables

Ehm IPSec kan je doorlaten door de volgende pakketen door te laten:
• IP Protocol ID 50 (ESP)
• IP Protocol ID 50 (AH)
• UDP Port 500 door te laten (IKE & ISAKMP)

En de commando's daarvoor zijn zelf wel uit te zoeken...

Tevens dit is ook te vinden bij mijn vrienden van Google door te zoeken op IPSec FireWall maar goed...

Edit : Links

Protocol Nummers : Linkje
IPChains Commando's : Linkje

vrijdag 19 april 2002 09:36

Acties:

Op donderdag 18 april 2002 13:24 schreef Birk het volgende:

[..]

Ehm IPSec kan je doorlaten door de volgende pakketen door te laten:
• IP Protocol ID 50 (ESP)
• IP Protocol ID 50 (AH)
• UDP Port 500 door te laten (IKE & ISAKMP)

En de commando's daarvoor zijn zelf wel uit te zoeken...

Tevens dit is ook te vinden bij mijn vrienden van Google door te zoeken op IPSec FireWall maar goed...

Edit : Links

Protocol Nummers : Linkje
IPChains Commando's : Linkje

Die poortnummer daar was ik al achter, maar moet je die in de FORWARD chain zetten of in de nat table en welke? postrouting of prerouting.

vrijdag 19 april 2002 10:55

Acties:

Op vrijdag 19 april 2002 09:36 schreef hightower het volgende:
...maar moet je die in de FORWARD chain zetten of in de nat table en welke? postrouting of prerouting.

Dit kan verschillen is je Linux bak zelf de IPSec machine of gewoon een NAT box waarover de IPSec verbinding moet gaan lopen...

Als hij het zelf is dan moet het volgens mij in de INPUT en de OUTPUT rules...

Anders moet hij de pakketjes door geven aan die bak erachter... (Forward / NAT)

zaterdag 20 april 2002 01:54

Acties:

Verwijderd

2 kleine correcties:
1- Protocol nr. AH = 51 (typo, niet?)
2- AH hoef je niet door te laten bij NAT (werkt dan toch niet) Raar dat ze dat in dat artikel van MS wel specificeren.

Mocht je IPSEC via je firewall willen proberen, dus zonder NAT: http://www.kame.net

Verder is het me via hier eindelijk duidelijk geworden dat ik geen ESP masquerading module nodig. Dat betekent dat het met mijn ADSL modem ook moet gaan werken. Bedankt

zaterdag 20 april 2002 12:10

Acties:

Op vrijdag 19 april 2002 10:55 schreef Birk het volgende:

[..]

Dit kan verschillen is je Linux bak zelf de IPSec machine of gewoon een NAT box waarover de IPSec verbinding moet gaan lopen...

Als hij het zelf is dan moet het volgens mij in de INPUT en de OUTPUT rules...

Anders moet hij de pakketjes door geven aan die bak erachter... (Forward / NAT)

Het is een NAT machine, ik weet dus alleen niet of ik een FORWARD moet doen of een nat en dan welke nat, postrouting of prerouting

zaterdag 20 april 2002 12:41

Acties:

Verwijderd

Heb je ipsec wel in je kernel mee gebakken ??

#ipsec
options IPSEC
options IPSEC_ESP
options IPSEC_DEBUG

die opties moeten in je kernel.

voor meer info over ipsec
http://freebsd.cg.nu/ipsec.html

zaterdag 20 april 2002 12:51

Acties:

Op zaterdag 20 april 2002 12:41 schreef BaseFreak het volgende:
Heb je ipsec wel in je kernel mee gebakken ??

#ipsec
options IPSEC
options IPSEC_ESP
options IPSEC_DEBUG

die opties moeten in je kernel.

voor meer info over ipsec
http://freebsd.cg.nu/ipsec.html

Nee, niet, maar die opties komen helemaal niet voor in mn .config file.

Ik heb kernel 2.4.18
RedHat 7.2
en het is de bedoeling dat het een host to gateway verbinding is die gerouteerd moet worden

zaterdag 20 april 2002 13:02

Acties:

Verwijderd

Topicstarter

Op zaterdag 20 april 2002 12:41 schreef BaseFreak het volgende:
Heb je ipsec wel in je kernel mee gebakken ??

#ipsec
options IPSEC
options IPSEC_ESP
options IPSEC_DEBUG

die opties moeten in je kernel.

voor meer info over ipsec
http://freebsd.cg.nu/ipsec.html

Op een interne server heb ik dat wel gedaan, maar op de firewall nog niet, moet ie dat ook hebben om te kunnen NATten? (althans.. volgens mij heb ik het niet mee gebakken, zal nog ff kijken)

maandag 22 april 2002 16:17

Acties:

Verwijderd

Topicstarter

Op zaterdag 20 april 2002 13:02 schreef quinty het volgende:

[..]
(althans.. volgens mij heb ik het niet mee gebakken, zal nog ff kijken)

Nee idd.... ik heb het niet mee gebakken

maandag 22 april 2002 19:59

Acties:

Op zaterdag 20 april 2002 01:54 schreef jansssens het volgende:
2 kleine correcties:
1- Protocol nr. AH = 51 (typo, niet?)
2- AH hoef je niet door te laten bij NAT (werkt dan toch niet) Raar dat ze dat in dat artikel van MS wel specificeren.

Verder is het me via hier eindelijk duidelijk geworden dat ik geen ESP masquerading module nodig. Dat betekent dat het met mijn ADSL modem ook moet gaan werken. Bedankt

Ehm ja inderdaad typ fout

Copy past etc

Nou geen dank zou ik zeggen...

Beetje late reactie maar ik zat weer is niet op te letten