PF et plusieurs fournisseur d'accès Internet

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PF et plusieurs fournisseur d'accès Internet

Raphael Berlamont
Bonjour,

Je ne sais pas trop comment introduire mon problème, donc rentrons
directement dans le vif du sujet...

J'ai un couple de soekris (NET5501), avec OpenBSD 4.5 dessus. Ces
boitiers me servent à filtrer le flux IP de mon entreprise, et à créer
des tunnels IPSec entre le réseau du siège et nos sites de production
(qui possèdent eux aussi leurs couples soekris) .

Au siège, nous avons deux connexions vers internet :
- une SDSL avec 4 IPs (FAIa, IPa1=>IPa4, GWa);
- une ADSL (FAIb, IPb, GWa).

La connectique est la suivante :
FAIa----|
        |switch|----|vr0  SOEKRIS  vr2|----|LAN/DMZ
FAIb----|

J'espère que le schéma restera compréhensible. Voici quelques
explication supplémentaires : les deux arrivées des FAI sont branchées
sur un switch. Ce même switch est à son tour relié sur la patte vr0 du
boitier soekris. L'interface vr2 du soekris est reliée au LAN.

Comme dit plus haut, ce sont des couples de soekris. Ils fonctionnent
donc avec pfsync, et CARP (et sasyncd, mais ce n'est pas le problème
ici).

Voici la sortie d'un ifconfig légèrement retouché niveau IP :
=======================
OpenBSD-4.5 anubisA ~ # ifconfig -A
lo0: flags=8149<UP,LOOPBACK,RUNNING,PROMISC,MULTICAST> mtu 33204
        priority: 0
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:cb:58:dc
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::200:24ff:fecb:58dc%vr0 prefixlen 64 scopeid 0x1
vr1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:cb:58:dd
        priority: 0
        media: Ethernet autoselect (none)
        status: no carrier
        inet6 fe80::200:24ff:fecb:58dd%vr1 prefixlen 64 scopeid 0x2
vr2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:cb:58:de
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.149.0.2 netmask 0xffffc000 broadcast 10.149.63.255
        inet6 fe80::200:24ff:fecb:58de%vr2 prefixlen 64 scopeid 0x3
vr3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:cb:58:df
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 172.16.0.1 netmask 0xffffff00 broadcast 172.16.0.255
        inet6 fe80::200:24ff:fecb:58df%vr3 prefixlen 64 scopeid 0x4
enc0: flags=0<> mtu 1536
        priority: 0
pfsync0: flags=41<UP,RUNNING> mtu 1500
        priority: 0
        pfsync: syncdev: vr3 maxupd: 128
        groups: carp pfsync
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33204
        priority: 0
        groups: pflog
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        priority: 0
        groups: tun
        inet 10.149.8.1 --> 10.149.8.2 netmask 0xffffffff
carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:01
        priority: 0
        carp: MASTER carpdev vr0 vhid 1 advbase 1 advskew 10
        groups: carp egress
        inet6 fe80::200:5eff:fe00:101%carp1 prefixlen 64 scopeid 0x7
        inet 89.132.88.54 netmask 0xffffff00 broadcast 89.132.88.255
carp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:02
        priority: 0
        carp: MASTER carpdev vr2 vhid 2 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:102%carp2 prefixlen 64 scopeid 0x8
        inet 10.149.0.1 netmask 0xffffc000 broadcast 10.149.63.255
carp3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:03
        priority: 0
        carp: MASTER carpdev vr2 vhid 3 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:103%carp3 prefixlen 64 scopeid 0x9
        inet 192.168.6.20 netmask 0xffffff00 broadcast 192.168.6.255
carp4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:04
        priority: 0
        carp: MASTER carpdev vr0 vhid 4 advbase 1 advskew 10
        groups: carp egress
        inet6 fe80::200:5eff:fe00:104%carp4 prefixlen 64 scopeid 0xa
        inet 142.18.76.90 netmask 0xfffffff8 broadcast 142.18.76.95
carp5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:05
        priority: 0
        carp: MASTER carpdev vr0 vhid 5 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:105%carp5 prefixlen 64 scopeid 0xb
        inet 142.18.76.91 netmask 0xfffffff8 broadcast 142.18.76.95
carp6: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:06
        priority: 0
        carp: MASTER carpdev vr0 vhid 6 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:106%carp6 prefixlen 64 scopeid 0xc
        inet 142.18.76.92 netmask 0xfffffff8 broadcast 142.18.76.95
carp7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:07
        priority: 0
        carp: MASTER carpdev vr0 vhid 7 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:107%carp7 prefixlen 64 scopeid 0xd
        inet 142.18.76.93 netmask 0xfffffff8 broadcast 142.18.76.95
carp8: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:08
        priority: 0
        carp: MASTER carpdev vr0 vhid 8 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:108%carp8 prefixlen 64 scopeid 0xe
        inet 142.18.76.94 netmask 0xfffffff8 broadcast 142.18.76.95
carp9: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:09
        priority: 0
        carp: MASTER carpdev vr2 vhid 9 advbase 1 advskew 10
        groups: carp
        inet6 fe80::200:5eff:fe00:109%carp9 prefixlen 64 scopeid 0xf
        inet 192.168.6.1 netmask 0xffffff00 broadcast 192.168.6.255
OpenBSD-4.5 anubisA ~ # route -n show
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            142.18.76.89      UGSP       8  2262901     -     8 carp4
default            89.132.88.254       UGSP       2   582476     -     8 carp1
10.149.0/18        link#3             UC         2        0     -     4 vr2
10.149.0.1         10.149.0.1         UH         1     7815     -     4 carp2
10.149.0.6         00:1e:c9:ec:34:e7  UHLc       2     1164     -     4 vr2
10.149.2.3         00:1e:37:cc:c1:60  UHLc       1      454     -     4 vr2
10.149.8/24        10.149.8.2         UGS        0    42610     -     8 tun0
10.149.8.2         10.149.8.1         UH         1        0     -     4 tun0
89.132.88/24        link#7             UC         0        0     -     4 carp1
81.57.32.254       00:07:cb:97:ac:57  UHLc       1        0     -     4 carp1
127/8              127.0.0.1          UGRS       0        0 33204     8 lo0
127.0.0.1          127.0.0.1          UH         1      302 33204     4 lo0
172.16.0/24        link#4             UC         0        0     -     4 vr3
192.168.6/24       link#9             UC         5        0     -     4 carp3
192.168.6.1        192.168.6.1        UH         1       20     -     4 carp9
192.168.6.2        00:06:5b:ef:3d:06  UHLc       1        1     -     4 carp3
192.168.6.167      00:e0:29:9a:84:c9  UHLc       0        2     -     4 carp3
192.168.6.203      00:0c:29:46:e3:c7  UHLc       0        1     -     4 carp3
192.168.6.212      00:50:56:9a:14:f7  UHLc       0        1     -     4 carp3
192.168.6.223      08:00:27:65:3f:69  UHLc       0        1     -     4 carp3
142.18.76.88/29   link#10            UC         1        0     -     4 carp4
142.18.76.89      00:1d:a2:c2:ce:60  UHLc       0        0     -     4 carp4
142.18.76.91      142.18.76.91      UH         0        0     -     4 carp5
142.18.76.92      142.18.76.92      UH         0        0     -     4 carp6
142.18.76.93      142.18.76.93      UH         0        0     -     4 carp7
142.18.76.94      142.18.76.94      UH         0        0     -     4 carp8
224/4              127.0.0.1          URS        0        0 33204     8 lo0

Internet6:
Destination                        Gateway                        
[...]

Encap:
Source             Port  Destination        Port  Proto SA(Address/Proto/Type/Direction)
[...]
OpenBSD-4.5 anubisA ~ #
=====================

Comme on peut le voir ci dessus, coté internet (vr0), nous avons 4+1
IPs :
- 142.18.76.90: FAIa, CARP4, GW=142.18.76.89 MAC_GW=00:1d:a2:c2:ce:60;
- 142.18.76.91: FAIa, CARP5, ";
- 142.18.76.92: FAIa, CARP6, ";
- 142.18.76.93: FAIa, CARP7, ";
- 142.18.76.94: FAIa, CARP8, ";
- 89.132.88.54: FAIb, CARP1, GW=89.132.88.254 MAC_GW=00:07:cb:97:ac:57.

Coté LAN, nous avons deux subnets (pour des raisons historiques) :
10.149.0.0/18 et 192.168.6.0/24, avec les IPs suivantes pour les
atteindre :
- 10.149.0.1 : IP CARP2 partagée;
- 10.149.0.2 : IP propre au soekris (principal);
- 192.168.6.1 : IP CARP9 partagée;
- 192.168.6.20 : IP CARP3 partagée, présente pour des raisons
historiques. Je pourrai la supprimer.

Le but d'avoir ces deus FAI est de redirigé le flux internet et autre
flux très consommateur sur la ligne ADSL, et faire transiter les flux
prioritaires sur la SDSL. Ceci fonctionne plutôt très bien du LAN vers
internet : les flux HTTP, et FTP sont redirigés vers la ligne ADSL. Je
ne constate pas de problème de fonctionnement.

Voici un résumé des règles que j'utilise pour effectuer ceci :
==================
# HTTP, FTP : On route le HTTP et le FTP vers l'ADSL
nat log on $WAN_IF from $LAN_NETWORK to any port { http, ftp } \
        -> ($WAN_FAIb_CARP_IF)
# Default on route tout le traffic non definie ci-dessus en sur les
interface ci-dessous
nat log on $WAN_IF from $LAN_NETWORK to any \
        -> ($WAN_FAIa90_CARP_IF)
[...]
# HTTP(S) : on autorise les gens à faire du HTTP(s)
pass in quick log on $LAN_IF route-to ($WAN_FAIb_CARP_IF 89.132.88.254)\
        inet proto tcp from $LAN_NETWORK to any port { http, ftp }
pass in quick log on $LAN_IF route-to ($WAN_FAIa_CARP_IF 142.18.76.89)\
        inet proto tcp from $LAN_NETWORK to any port { https }
==================

Bon, c'est vraiment du résumé, mais ça marche bien.

Le problème que je rencontre est le suivant :
j'héberge en interne quelques serveurs accessibles de l'extérieur. Je
fait donc de la redirection :
==================
rdr pass log on $WAN_IF from any to $FAIa_IP_3 -> $DEMO_IP
==================

Le paquet arrivent bien jusqu'au serveur en interne, en repartent bien,
arrive jusqu'au soekris, et parte bien sur soekris... mais vers la
mauvaise GW.
En gros le paquet arrivent sur l'interface publique CARP7 sur l'IP
142.18.76.93, et ceux-ci sont redirigés vers l'IP interne 10.149.0.200 :
==================
Nov 16 01:32:49.725523 rule 14/(match) rdr in on vr0: 88.191.98.203.45002 > 10.149.0.200.80: S 1746522046:1746522046(0) win 5840 <mss 1460,sackOK,timestamp 3856999604[|tcp]> (DF)
Nov 16 01:32:49.725595 rule 15/(match) pass out on vr2: 88.191.98.203.45002 > 10.149.0.200.80: S 1746522046:1746522046(0) win 5840 <mss 1460,sackOK,timestamp 3856999604[|tcp]> (DF)
==================

Pour le reste des capture, j'ai été obligé de passé non plus sur
l'interface pflog, mais sur les interfaces physiques directement :
==================
OpenBSD-4.5 anubisA ~ # tcpdump -nettti vr2 host 88.191.98.203            
tcpdump: listening on vr2, link-type EN10MB
Nov 16 01:33:35.873434 00:00:24:cb:58:de 00:0c:29:3f:11:6f 0800 74: 88.191.98.203.45003 > 10.149.0.200.80: S 2463407432:2463407432(0) win 5840 <mss 1460,sackOK,timestamp 3857013449 0,nop,wscale 7> (DF)
Nov 16 01:33:35.873790 00:0c:29:3f:11:6f 00:00:5e:00:01:02 0800 74: 10.149.0.200.80 > 88.191.98.203.45003: S 1499725615:1499725615(0) ack 2463407433 win 5792 <mss 1460,sackOK,timestamp 117353858 3857013449,nop,wscale 7> (DF)
==================
Le serveur internet renvoit donc bien sa réponse sur sa passerelle par
défaut (10.149.0.1) correspondant au soekris.

Ceux-ci sont bien récupérés par le soekris, qui tente de les renvoyer :
==================
OpenBSD-4.5 anubisA ~ # tcpdump -nettti vr0 host 88.191.98.203
tcpdump: listening on vr0, link-type EN10MB
Nov 16 01:34:10.464233 00:1d:a2:c2:ce:60 00:00:5e:00:01:07 0800 74: 88.191.98.203.45004 > 142.18.76.93.80: S 3006163274:3006163274(0) win 5840 <mss 1460,sackOK,timestamp 3857023832 0,nop,wscale 7> (DF)
Nov 16 01:34:10.465029 00:00:24:cb:58:dc 00:07:cb:97:ac:57 0800 74: 142.18.76.93.80 > 88.191.98.203.45004: S 1518031858:1518031858(0) ack 3006163275 win 5792 <mss 1460,sackOK,timestamp 117362504 3857023832,nop,wscale 7> (DF)
==================
On voit bien ci-dessus le paquet arriver (SYN), et tenter de
repartir(SYN/ACK). Le problème se trouve sur la seconde ligne : le
paquet est émis vers la GWb (du FAIb donc) avec l'IPa3 (du FAIa donc).
Évidement, le paquet est droppé au premier saut, la GWb n'acceptant pas
une autre IP source que IPb.

J'ai essayé d'ajouter la règle suivante :
==================
pass in quick log on $LAN_IF route-to ($WAN_FAIa3_CARP_IF \
        142.18.76.89) inet proto tcp from $DEMO_IP port 80 \
        to any
==================
Et même :
==================
pass in quick log on $LAN_IF route-to ($WAN_FAIa3_CARP_IF 142.18.76.89)\
        inet proto tcp from $DEMO_IP to any
==================

Mais rien à faire, ma passerelle s'en-tête à vouloir envoyer les
réponses sur GWb avec comme IP source IPa3.

J'ai pas mal creusé et lu la doc de PF, mais je n'ai pas réussi à
pointer d'où pouvait venir le problème, ni trouvé comment forcé l'envoi
de vers une GW pour un paquet en retour du réseau interne.

Auriez-vous une piste?

Bonne soirée,
--
Raph





________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml

Reply | Threaded
Open this post in threaded view
|

Re: PF et plusieurs fournisseur d'accès Internet

Raphael Berlamont
Le lundi 16 novembre 2009 à 01:50 +0100, Raphael Berlamont a écrit :

J'apporte une correction :

> Au siège, nous avons deux connexions vers internet :
> - une SDSL avec 4 IPs (FAIa, IPa1=>IPa4, GWa);
> - une ADSL (FAIb, IPb, GWa).

il fallait lire ci-dessus :
- une ADSL (FAIb, IPb, GWb).

Bonne soirée,
--
Raph



________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml

Reply | Threaded
Open this post in threaded view
|

Re: Re: PF et plusieurs fournisseur d'accès Internet

Julien C-2
Bonjour,

Avez vous regardé reply-to / route-to ??

Cdt,



Le 16 novembre 2009 18:12, Raphael Berlamont
<[hidden email]>a écrit :

> Le lundi 16 novembre 2009 à 01:50 +0100, Raphael Berlamont a écrit :
>
> J'apporte une correction :
>
> > Au siège, nous avons deux connexions vers internet :
> > - une SDSL avec 4 IPs (FAIa, IPa1=>IPa4, GWa);
> > - une ADSL (FAIb, IPb, GWa).
>
> il fallait lire ci-dessus :
> - une ADSL (FAIb, IPb, GWb).
>
> Bonne soirée,
> --
> Raph
>
>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/ml
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: PF et plusieurs fournisseur d'accès Internet

Raphael Berlamont
Le lundi 16 novembre 2009 à 19:24 +0100, julien c a écrit :
> Bonjour,
>
> Avez vous regardé reply-to / route-to ??

"route-to" oui. C'est d'ailleurs ce que j'utilise pour forcer
l'utilisation d'une ligne en particulier suivant le type de traffic (du
LAN vers Internet).

Par contre, je n'ai pas utilisé "reply-to" (ce qui pourrait-être ma
solution) car je n'ai pas trouvé d'exemple concret dans la doc (ni sur
le net), et ne comprends pas trop son cadre d'utilisation et son
fonctionnement. Je suis preneur si vous avez des infos.

Bonne journée,
--
Raph



________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml

Reply | Threaded
Open this post in threaded view
|

Re: Re: PF et plusieurs fournisseur d'accès Internet

Laurent Cheylus
Bonjour,

On Tue, Nov 17, 2009 at 10:19:47AM +0100, Raphael Berlamont wrote:
> Par contre, je n'ai pas utilisé "reply-to" (ce qui pourrait-être ma
> solution) car je n'ai pas trouvé d'exemple concret dans la doc (ni sur
> le net), et ne comprends pas trop son cadre d'utilisation et son
> fonctionnement. Je suis preneur si vous avez des infos.

C'est bien "reply-to" qu'il faut utiliser pour spécifier la gateway de
sortie pour les paquets retour (SYN/ACK en réponse à la connexion
entrante vers vos serveurs). Effectivement, il n'y a pas beaucoup de doc
sur le sujet (pas d'exemple dans la manpage pf.conf, ni dans la FAQ, pas
mieux dans le "Book of PF"...).

Extrait de la manpage pf.conf :

reply-to

The reply-to option is similar to route-to, but routes packets that pass
in the opposite direction (replies) to the specified interface.
Opposite direction is only defined in the context of a state entry, and
reply-to is useful only in rules that create state.  It can be used on
systems with multiple external connections to route all outgoing packets
of a connection through the interface the incoming connection arrived
through (symmetric routing enforcement).

Voir ce post qui donne un exemple de règle PF avec reply-to :

http://lists.freebsd.org/pipermail/freebsd-pf/2005-November/001615.html

A++ Laurent

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml

Reply | Threaded
Open this post in threaded view
|

Re: Re: PF et plusieurs fournisseur d'accès Internet

Raphael Berlamont
Le mardi 17 novembre 2009 à 14:05 +0100, Laurent Cheylus a écrit :
> C'est bien "reply-to" qu'il faut utiliser pour spécifier la gateway de
> sortie pour les paquets retour (SYN/ACK en réponse à la connexion
> entrante vers vos serveurs). Effectivement, il n'y a pas beaucoup de doc
> sur le sujet (pas d'exemple dans la manpage pf.conf, ni dans la FAQ, pas
> mieux dans le "Book of PF"...).

Ni dans le bouquin de Jacek Artymiak...

> Extrait de la manpage pf.conf :
>
> reply-to
[...]

Sans un exemple pour étayer l'explication, c'est dur.

> Voir ce post qui donne un exemple de règle PF avec reply-to :
>
> http://lists.freebsd.org/pipermail/freebsd-pf/2005-November/001615.html

Voici ce que j'ai essayé :
=====================
nat log (all) on $WAN_IF from $LAN_NETWORK to any port { http } -> \
        ($WAN_FAIb_CARP_IF)
nat log (all) on $WAN_IF from $LAN_NETWORK to any -> \
        ($WAN_FAIa90_CARP_IF)

rdr log (all) on $WAN_IF proto tcp from any to $FAIa_IP_MAIN \
        port 8443 -> $DEMO_IP port https

pass out log (all) all
pass in quick log (all) on $WAN_IF \
        reply-to ( $WAN_FAIa90_CARP_IF 142.18.76.89 ) proto tcp \
        from any to $DEMO_IP port { http, https } flags S/SA
=====================

J'ai maintenant un comportement étrange, plus rien n'apparait sur
l'interface pflog en sur le port 8443 :
=====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 8443
tcpdump: listening on pflog0, link-type PFLOG
^C
2799 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
=====================

Par contre, si je filtre sur le port de redirection interne :
=====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 443
tcpdump: listening on pflog0, link-type PFLOG
Nov 17 23:33:56.568765 rule 39/(match) [uid 0, pid 16354] pass in on vr0: 88.191.98.203.41632 > 10.149.0.200.443: S 1086982160:1086982160(0) win 5840 <mss 1460,sackOK,timestamp 3906699572[|tcp]> (DF) (ttl 54, id 35108, len 60)
Nov 17 23:33:56.568858 rule 15/(match) [uid 0, pid 16354] pass out on vr2: 88.191.98.203.41632 > 10.149.0.200.443: S 1086982160:1086982160(0) win 5840 <mss 1460,sackOK,timestamp 3906699572[|tcp]> (DF) (ttl 53, id 35108, len 60)
Nov 17 23:33:56.569409 rule 15/(match) [uid 0, pid 16354] pass in on vr2: 10.149.0.200.443 > 88.191.98.203.41632: S 276258896:276258896(0) ack 1086982161 win 5792 <mss 1460,sackOK,timestamp 158753551[|tcp]> (DF) (ttl 64, id 0, len 60)
Nov 17 23:33:56.569462 rule 11/(match) [uid 0, pid 16354] rdr out on vr0: 10.149.0.200.443 > 88.191.98.203.41632: S 276258896:276258896(0) ack 1086982161 win 5792 <mss 1460,sackOK,timestamp 158753551[|tcp]> (DF) (ttl 63, id 0, len 60)
[...]
^C
1876 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
=====================
On voit bien le paquet qui arrive, qui est ensuite translaté en interne,
puis revenir vers l'interface externe.

Seulement, lorsque je capture vr0, je ne vois rien ressortir (en
filtrant sur le port d'écoute externe) :
=====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr0 host 88.191.98.203 and \( port 8443 or port 443 \)
tcpdump: listening on vr0, link-type EN10MB
Nov 18 00:19:14.922294 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.54136 > 142.18.76.90.8443: S [tcp sum ok] 757957628:757957628(0) win 5840 <mss 1460,sackOK,timestamp 3907515101 0,nop,wscale 7> (DF) (ttl 54, id 28961, len 60)
^C
6087 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
=====================

Par contre, si je filtre sur le port 443 sur l'interface interne, j'ai
ceci :
=====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr2 host 88.191.98.203 and port 443
tcpdump: listening on vr2, link-type EN10MB
Nov 17 23:35:53.790108 00:00:24:cb:58:de 00:0c:29:3f:11:6f 0800 74: 88.191.98.203.47173 > 10.149.0.200.443: S [tcp sum ok] 2929174408:2929174408(0) win 5840 <mss 1460,sackOK,timestamp 3906734740 0,nop,wscale 7> (DF) (ttl 53, id 44316, len 60)
Nov 17 23:35:53.790715 00:0c:29:3f:11:6f 00:00:5e:00:01:02 0800 74: 10.149.0.200.443 > 88.191.98.203.47173: S [tcp sum ok] 421952315:421952315(0) ack 2929174409 win 5792 <mss 1460,sackOK,timestamp 158782852 3906734740,nop,wscale 7> (DF) (ttl 64, id 0, len 60)
Nov 17 23:35:56.794351 00:0c:29:3f:11:6f 00:00:5e:00:01:02 0800 74: 10.149.0.200.443 > 88.191.98.203.47173: S [tcp sum ok] 421952315:421952315(0) ack 2929174409 win 5792 <mss 1460,sackOK,timestamp 158783603 3906734740,nop,wscale 7> (DF) (ttl 64, id 0, len 60)
[...]
^C
24098 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
====================

Pour rappel, je ne vois rien ressortir sur vr0, quel que soit le port
(8443 ou 443) :
====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr0 host 88.191.98.203 and \( port 8443 or port 443 \)
tcpdump: listening on vr0, link-type EN10MB
Nov 18 00:23:16.802093 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.41941 > 142.18.76.90.8443: S [tcp sum ok] 257437682:257437682(0) win 5840 <mss 1460,sackOK,timestamp 3907587661 0,nop,wscale 7> (DF) (ttl 54, id 8639, len 60)
Nov 18 00:23:17.801615 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.41942 > 142.18.76.90.8443: S [tcp sum ok] 275041377:275041377(0) win 5840 <mss 1460,sackOK,timestamp 3907587962 0,nop,wscale 7> (DF) (ttl 54, id 49947, len 60)
^C
4701 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
====================

Alors que, sans changer les règles, les connexions initiées de
l'intérieur (à partir du serveur interne concerné) sont correctement
nattées :
====================
OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 80
tcpdump: listening on pflog0, link-type PFLOG
Nov 18 00:08:26.178774 rule 170/(match) [uid 0, pid 8113] pass in on vr2: 10.149.0.200.59399 > 88.191.98.203.80: S 2470268420:2470268420(0) win 5840 <mss 1460,sackOK,timestamp 159270884[|tcp]> (DF) (ttl 64, id 2528, len 60)
Nov 18 00:08:26.178873 rule 15/(match) [uid 0, pid 8113] pass out on vr0: 89.132.88.54.62277 > 88.191.98.203.80: S 2470268420:2470268420(0) win 5840 <mss 1460,sackOK,timestamp 159270884[|tcp]> (DF) (ttl 64, id 2528, len 60)
Nov 18 00:08:26.199044 rule 1/(match) [uid 0, pid 8113] nat in on vr0: 88.191.98.203.80 > 10.149.0.200.59399: S 3477865083:3477865083(0) ack 2470268421 win 5792 <mss 1460,sackOK,timestamp 3907320559[|tcp]> (DF) (ttl 59, id 0, len 60)
Nov 18 00:08:26.199095 rule 170/(match) [uid 0, pid 8113] pass out on vr2: 88.191.98.203.80 > 10.149.0.200.59399: S 3477865083:3477865083(0) ack 2470268421 win 5792 <mss 1460,sackOK,timestamp 3907320559[|tcp]> (DF) (ttl 58, id 0, len 60)
Nov 18 00:08:26.199595 rule 170/(match) [uid 0, pid 8113] pass in on vr2: 10.149.0.200.59399 > 88.191.98.203.80: . [tcp sum ok] 1:1(0) ack 1 win 46 <nop,nop,timestamp 159270890 3907320559> (DF) (ttl 64, id 2529, len 52)
Nov 18 00:08:26.199617 rule 1/(match) [uid 0, pid 8113] nat out on vr0: 89.132.88.54.62277 > 88.191.98.203.80: . [tcp sum ok] 2470268421:2470268421(0) ack 3477865084 win 46 <nop,nop,timestamp 159270890 3907320559> (DF) (ttl 64, id 2529, len 52)
[...]
^C
2474 packets received by filter
0 packets dropped by kernel
OpenBSD-4.5 anubisA ~ #
====================
Celà-dit, je me méprends peut-être sur l'utilisation des mots-clefs
"rdr" et "nat" dans les sorties de pflog0 suivant le sens des
connexions...

Je suis donc encore bloqué, même s'il y a de fortes chances pour que
"reply-to" soit la bonne solution, je n'arrive pas à bien l'utiliser.

Je suis ouvert à toute suggestion.

Bonne soirée,
--
Raph



________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml

Reply | Threaded
Open this post in threaded view
|

Re: Re: PF et plusieurs fournisseur d'accès Internet

Jérôme Loyet-4
Le 18 novembre 2009 00:31, Raphael Berlamont
<[hidden email]> a écrit :

> Le mardi 17 novembre 2009 à 14:05 +0100, Laurent Cheylus a écrit :
>> C'est bien "reply-to" qu'il faut utiliser pour spécifier la gateway de
>> sortie pour les paquets retour (SYN/ACK en réponse à la connexion
>> entrante vers vos serveurs). Effectivement, il n'y a pas beaucoup de doc
>> sur le sujet (pas d'exemple dans la manpage pf.conf, ni dans la FAQ, pas
>> mieux dans le "Book of PF"...).
>
> Ni dans le bouquin de Jacek Artymiak...
>
>> Extrait de la manpage pf.conf :
>>
>> reply-to
> [...]
>
> Sans un exemple pour étayer l'explication, c'est dur.
>
>> Voir ce post qui donne un exemple de règle PF avec reply-to :
>>
>> http://lists.freebsd.org/pipermail/freebsd-pf/2005-November/001615.html
>
> Voici ce que j'ai essayé :
> =====================
> nat log (all) on $WAN_IF from $LAN_NETWORK to any port { http } -> \
>        ($WAN_FAIb_CARP_IF)
> nat log (all) on $WAN_IF from $LAN_NETWORK to any -> \
>        ($WAN_FAIa90_CARP_IF)
>
> rdr log (all) on $WAN_IF proto tcp from any to $FAIa_IP_MAIN \
>        port 8443 -> $DEMO_IP port https
>
> pass out log (all) all
> pass in quick log (all) on $WAN_IF \
>        reply-to ( $WAN_FAIa90_CARP_IF 142.18.76.89 ) proto tcp \
>        from any to $DEMO_IP port { http, https } flags S/SA
> =====================
>
> J'ai maintenant un comportement étrange, plus rien n'apparait sur
> l'interface pflog en sur le port 8443 :
> =====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 8443
> tcpdump: listening on pflog0, link-type PFLOG
> ^C
> 2799 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> =====================
>
> Par contre, si je filtre sur le port de redirection interne :
> =====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 443
> tcpdump: listening on pflog0, link-type PFLOG
> Nov 17 23:33:56.568765 rule 39/(match) [uid 0, pid 16354] pass in on vr0: 88.191.98.203.41632 > 10.149.0.200.443: S 1086982160:1086982160(0) win 5840 <mss 1460,sackOK,timestamp 3906699572[|tcp]> (DF) (ttl 54, id 35108, len 60)
> Nov 17 23:33:56.568858 rule 15/(match) [uid 0, pid 16354] pass out on vr2: 88.191.98.203.41632 > 10.149.0.200.443: S 1086982160:1086982160(0) win 5840 <mss 1460,sackOK,timestamp 3906699572[|tcp]> (DF) (ttl 53, id 35108, len 60)
> Nov 17 23:33:56.569409 rule 15/(match) [uid 0, pid 16354] pass in on vr2: 10.149.0.200.443 > 88.191.98.203.41632: S 276258896:276258896(0) ack 1086982161 win 5792 <mss 1460,sackOK,timestamp 158753551[|tcp]> (DF) (ttl 64, id 0, len 60)
> Nov 17 23:33:56.569462 rule 11/(match) [uid 0, pid 16354] rdr out on vr0: 10.149.0.200.443 > 88.191.98.203.41632: S 276258896:276258896(0) ack 1086982161 win 5792 <mss 1460,sackOK,timestamp 158753551[|tcp]> (DF) (ttl 63, id 0, len 60)
> [...]
> ^C
> 1876 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> =====================
> On voit bien le paquet qui arrive, qui est ensuite translaté en interne,
> puis revenir vers l'interface externe.
>
> Seulement, lorsque je capture vr0, je ne vois rien ressortir (en
> filtrant sur le port d'écoute externe) :
> =====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr0 host 88.191.98.203 and \( port 8443 or port 443 \)
> tcpdump: listening on vr0, link-type EN10MB
> Nov 18 00:19:14.922294 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.54136 > 142.18.76.90.8443: S [tcp sum ok] 757957628:757957628(0) win 5840 <mss 1460,sackOK,timestamp 3907515101 0,nop,wscale 7> (DF) (ttl 54, id 28961, len 60)
> ^C
> 6087 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> =====================
>
> Par contre, si je filtre sur le port 443 sur l'interface interne, j'ai
> ceci :
> =====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr2 host 88.191.98.203 and port 443
> tcpdump: listening on vr2, link-type EN10MB
> Nov 17 23:35:53.790108 00:00:24:cb:58:de 00:0c:29:3f:11:6f 0800 74: 88.191.98.203.47173 > 10.149.0.200.443: S [tcp sum ok] 2929174408:2929174408(0) win 5840 <mss 1460,sackOK,timestamp 3906734740 0,nop,wscale 7> (DF) (ttl 53, id 44316, len 60)
> Nov 17 23:35:53.790715 00:0c:29:3f:11:6f 00:00:5e:00:01:02 0800 74: 10.149.0.200.443 > 88.191.98.203.47173: S [tcp sum ok] 421952315:421952315(0) ack 2929174409 win 5792 <mss 1460,sackOK,timestamp 158782852 3906734740,nop,wscale 7> (DF) (ttl 64, id 0, len 60)
> Nov 17 23:35:56.794351 00:0c:29:3f:11:6f 00:00:5e:00:01:02 0800 74: 10.149.0.200.443 > 88.191.98.203.47173: S [tcp sum ok] 421952315:421952315(0) ack 2929174409 win 5792 <mss 1460,sackOK,timestamp 158783603 3906734740,nop,wscale 7> (DF) (ttl 64, id 0, len 60)
> [...]
> ^C
> 24098 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> ====================
>
> Pour rappel, je ne vois rien ressortir sur vr0, quel que soit le port
> (8443 ou 443) :
> ====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti vr0 host 88.191.98.203 and \( port 8443 or port 443 \)
> tcpdump: listening on vr0, link-type EN10MB
> Nov 18 00:23:16.802093 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.41941 > 142.18.76.90.8443: S [tcp sum ok] 257437682:257437682(0) win 5840 <mss 1460,sackOK,timestamp 3907587661 0,nop,wscale 7> (DF) (ttl 54, id 8639, len 60)
> Nov 18 00:23:17.801615 00:1d:a2:c2:ce:60 00:00:5e:00:01:04 0800 74: 88.191.98.203.41942 > 142.18.76.90.8443: S [tcp sum ok] 275041377:275041377(0) win 5840 <mss 1460,sackOK,timestamp 3907587962 0,nop,wscale 7> (DF) (ttl 54, id 49947, len 60)
> ^C
> 4701 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> ====================
>
> Alors que, sans changer les règles, les connexions initiées de
> l'intérieur (à partir du serveur interne concerné) sont correctement
> nattées :
> ====================
> OpenBSD-4.5 anubisA ~ # tcpdump -vvvv -nettti pflog0 host 88.191.98.203 and port 80
> tcpdump: listening on pflog0, link-type PFLOG
> Nov 18 00:08:26.178774 rule 170/(match) [uid 0, pid 8113] pass in on vr2: 10.149.0.200.59399 > 88.191.98.203.80: S 2470268420:2470268420(0) win 5840 <mss 1460,sackOK,timestamp 159270884[|tcp]> (DF) (ttl 64, id 2528, len 60)
> Nov 18 00:08:26.178873 rule 15/(match) [uid 0, pid 8113] pass out on vr0: 89.132.88.54.62277 > 88.191.98.203.80: S 2470268420:2470268420(0) win 5840 <mss 1460,sackOK,timestamp 159270884[|tcp]> (DF) (ttl 64, id 2528, len 60)
> Nov 18 00:08:26.199044 rule 1/(match) [uid 0, pid 8113] nat in on vr0: 88.191.98.203.80 > 10.149.0.200.59399: S 3477865083:3477865083(0) ack 2470268421 win 5792 <mss 1460,sackOK,timestamp 3907320559[|tcp]> (DF) (ttl 59, id 0, len 60)
> Nov 18 00:08:26.199095 rule 170/(match) [uid 0, pid 8113] pass out on vr2: 88.191.98.203.80 > 10.149.0.200.59399: S 3477865083:3477865083(0) ack 2470268421 win 5792 <mss 1460,sackOK,timestamp 3907320559[|tcp]> (DF) (ttl 58, id 0, len 60)
> Nov 18 00:08:26.199595 rule 170/(match) [uid 0, pid 8113] pass in on vr2: 10.149.0.200.59399 > 88.191.98.203.80: . [tcp sum ok] 1:1(0) ack 1 win 46 <nop,nop,timestamp 159270890 3907320559> (DF) (ttl 64, id 2529, len 52)
> Nov 18 00:08:26.199617 rule 1/(match) [uid 0, pid 8113] nat out on vr0: 89.132.88.54.62277 > 88.191.98.203.80: . [tcp sum ok] 2470268421:2470268421(0) ack 3477865084 win 46 <nop,nop,timestamp 159270890 3907320559> (DF) (ttl 64, id 2529, len 52)
> [...]
> ^C
> 2474 packets received by filter
> 0 packets dropped by kernel
> OpenBSD-4.5 anubisA ~ #
> ====================
> Celà-dit, je me méprends peut-être sur l'utilisation des mots-clefs
> "rdr" et "nat" dans les sorties de pflog0 suivant le sens des
> connexions...
>
> Je suis donc encore bloqué, même s'il y a de fortes chances pour que
> "reply-to" soit la bonne solution, je n'arrive pas à bien l'utiliser.
>
> Je suis ouvert à toute suggestion.

Perso je ne peux pas t'aider car je n'ai pas dépasser les basics avec
PF, mais n'as tu pas demander directement sur misc@ ? ou meme
directement à henning@ ou claudio@ car j'ai l'impression qu'ils sont
bien actifs sur pf dans les sources
(http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/parse.y)

>
> Bonne soirée,
> --
> Raph
>
>
>
> ________________________________
> French OpenBSD mailing list
> [hidden email]
> http://www.openbsd-france.org/ml
>
>

________________________________
French OpenBSD mailing list
[hidden email]
http://www.openbsd-france.org/ml