Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Firewall Builder with multiple ISP connections howto

I’ve been using Firewall Builder to manage Linux (CentOS) firewalls for a while. It’s an excellent tool for middle-sized organizations.

I was a happy sysadmin with my single-ISP fwbuilder configuration. Everything was simple, everything worked out of the box. One day, a PPPoE connection came by. I thought there was a simple solution built into Firewall Builder to cope with two ISP connections, but after a lot of googling, I found that there was a lot of people asking and just a few people giving directions to the starting point.

My goal was to keep most of the Internet traffic through the old ISP connection, which has a static IP, and browse the Internet through the PPPoE connection. All of this using Firewall Builder to manage my firewall.

Well then. Here’s how I did it.

Configure the PPPoE interface as a secondary connection

There are some considerations for a PPPoE interface when it’s going to work as a secondary connection (i.e. not the default route). Please read my post about PPPoE in a multiple-connection Linux firewall.

FWBuilder Policy Rules

Besides the rules that allow traffic (action “Accept”), the policy must include a rule with action “Tag” to mark packets to be routed through the secondary Internet connection.

TagService

Define a TagService object (Services > TagServices) in your Firewall Builder configuration:

Name

TagPPPoE

Code

4

Comment

Tag service to mark traffic routed through the PPPoE connection.

IMPORTANT: the code value must match the MARK variable from file “/etc/init.d/ip_rules”.

I’ll explain file “/etc/init.d/ip_rules” later.

Policy rules

You must create at least two rules to allow HTTP and HTTPS to be routed through the secondary Internet connection, one rule to mark packets and another one to allow traffic. Both are very similar, so differences are in bold for ease of reading:

Source

Source IP address for HTTP and HTTPS traffic

Destination

Any

Service

http, https

Interface

Your firewall internal network interface

Direction

Inbound

Action

Tag (select the “TagPPPoE” TagService)

Time

Any

Options

(leave empty)

Comment

Tagging to let HTTP and HTTPS be routed through the PPPoE interface

Source

Source IP address for HTTP and HTTPS traffic

Destination

Any

Service

http, https

Interface

Your firewall internal network interface

Direction

Inbound

Action

Accept

Time

Any

Options

(leave empty)

Comment

Allow HTTP and HTTPS to the Internet

FWBuilder NAT Rules

You must create two separate NAT rules for outgoing network traffic, one rule for protocols routed through the secondary Internet connection and one for all the other network traffic. The order is important.

In the example, “fw-Static” and “fw-PPPoE” are the network interfaces for the static IP and the PPPoE (secondary) Internet connections respectively.

Original Src

IP’s of the internal network

Original Dst

Any

Original Srv

http, https

Translated Src

fw-PPPoE

Translated Dst

Original

Translated Srv

Original

Action

Translate

Options

(leave empty)

Comment

NAT rule to browse the Internet

Original Src

IP’s of the internal network

Original Dst

Any

Original Srv

Any

Translated Src

fw-Static

Translated Dst

Original

Translated Srv

Original

Action

Translate

Options

(leave empty)

Comment

Default outgoing NAT rule

You may need to add one NAT rule for each Internet connection.

Setting up the routing rules

The routing tables and ip rules are set outside Firewall Builder. Even though I may have used FWBuilder’s Epilog to add this code inside the policy, I preferred to create an RC script to load routing configuration right after the network RC script is executed.

You may download the “/etc/init.d/ip_rules” RC script from this link.

Update routing tables when PPPoE changes the IP

Every time the PPPoE connection changes its IP, the references to this interface in the routing tables are erased! The secondary routing table has the ppp0 interface as the default route, so you will lose your routing capabilities every time the PPPoE IP changes. Unless you do something :-)

To automatically configure the routing information every time the PPPoE interface changes, add the following commands to file /etc/ppp/ip-up.local:

/etc/init.d/ip_rules start

Troubleshooting

Try the simplest FWBuilder Policy first (or even no FWBuilder policy at all)

Create the simplest policy in FWBuilder (i.e. allow all outgoing traffic, NATed with the external static IP) and then start adding the routing functionality. If it doesn’t work, try creating simple iptables rules to avoid using FWBuilder while configuring ip rules and routes.

Once the traffic routing is working, let FWBuilder join the party.

FWBuilder’s Kernel anti-spoofing protection

This option made me loose a lot of time!

You may find this firewall option in “Host OS Settings > Options > Kernel anti-spoofing protection”. It was set with value “On” and I changed it to “No Change” to make routing work correctly.

The symptoms were that returning TCP packets arrived correctly to the external PPPoE interface, but did not arrive to the internal Ethernet interface (I used “tcpdump” to see this). It worked right without applying FWBuilder policy, so I started diving into FWBuilder configuration, looking for uncommon things, until I found this option to be the root of all evil… several extra hours later :-(

Conclusion

This solution allows the Firewall administrator to easily modify the traffic routed through the secondary Internet connection. Routing other traffic through additional network interfaces may require changes in the “/etc/init.d/ip_rules” RC script (just another routing table and another ip rule), but network interfaces seldom change, so 99% of the job is done through Firewall Builder.

  • Delicious
  • Facebook
  • Digg
  • Reddit
  • StumbleUpon
  • Twitter

9 comments to Firewall Builder with multiple ISP connections howto

  • David

    Buenas marcos,
    he estado siguiendo tu blog y ahora me he encontrado con la necesidad de montar un firewall con 3 ADSL y he intentado seguir tus recomendaciones pero por algún motivo no me va.

    Estoy usando Centos 5.3 y FWBuilder 4.1
    Eth0 – ADSL1 192.168.201.6/24 Gw 192.168.201.1
    Eth1 – ADSL2 192.168.202.6/24 Gw 192.168.202.1
    Eth2 – LAN 192.168.2.6/24 Adsl pruebas 192.168.2.5
    Eth3 – ADSL3 192.168.203.6/24 Gw 192.168.203.1

    En mi caso en vez de tener una conexion PPPoE dispongo de 3 ADSL con IP fija en modo NAT, por lo que las interfaces de red no tienen el acceso directo hacia internet.

    Las Pruebas las estoy realizando con la eth2 para LAN y ETH0 para enrurtar mi workstation por esa ADSL.

    He bajado tu script ip_rules y lo he modificado para cambiar el interface ppp0 por la eth1 que es la ADSL que me quiero asignar, parece que marca bien los paquetes pero por algun motivo no salgo hacia internet. He Creado las Policy, NAT, TAGS pero por algun motivo no me saca a internet.

    Alguna sugerencia?

    Muchas gracias
    david

  • Qué tal David.

    Te recomiendo que verifiques lo siguiente:

    1) Asegurate de verificar lo que puse en la sección “Troubleshooting”. Los peligros que advierto en esa sección me hicieron perder muchas horas :-( Creo que esa sección es el verdadero aporte del post :-)

    2) Como prueba, deshabilitá momentáneamente el SELinux. Cuando tengo un problema al cual no puedo encontrarle la causa, la mayoría de las veces se debe al SELinux.

    3) tcpdump es tu amigo :-) Este comando me ha ayudado a resolver muchos problemas mostrándome cómo son los paquetes que llegan a cada interfaz.

    4) Verificá que no tengas problemas de ruteo en tu firewall. Para eso, es muy útil crear una policy muy pero muy simple, que deje pasar todo y tenga las reglas de NAT mínimas.

    5) Verificá que no tengas problemas de ruteo con los routers que te conectan a Internet. Esto podrías verificarlo conectando un notebook u otro PC con un cable UTP cruzado a la interfaz eth1 (es decir, a la interfaz por la que querés que salgan tus paquetes marcados). Al notebook deberías ponerle la configuración IP del router al que se conecta la interfaz eth1. Ejecutando un tcpdump en el notebook, podrás ver si los paquetes que salen del firewall son correctos. Si es así, tal vez haya un problema de ruteo en el router y no en el firewall. Esta prueba podrías repetirla en la interfaz eth2 (LAN), posiblemente desde tu PC, para ver cómo son los paquetes que vuelven del firewal (si es que vuelven).

    En fin, esos son algunos consejos. Mucho tcpdump para ver qué pasa. En mi caso creo que estuve el 80% del tiempo tratando de descubrir por qué los paquetes no volvían del firewall al PC de la LAN. Es decir, desde un PC me conectaba al firewall, éste los marcaba y los ruteaba correctamente, iban hasta el servidor correcto en Internet, volvían al firewall y luego éste no enviaba ningún paquete al PC. Finalmente me puse a probar con las opciones del objeto del firewall dentro de Firewall Builder y resultó ser que la protección anti-spoofing no aceptaba los paquetes que llegaban al firewall desde Internet.

    Espero que te sirvan mis aportes.

    Saludos,

    Marcos

  • David

    Muchas gracias por tu respuesta. Al final lo solucione anoche dándole vueltas a tu Script ip_rules.

    En tu caso al tener una conexión PPPoE el Device ya tiene el default Gateway, en mi caso tenia que especificarlo. Modificando esta linea del código me empezó a funcionar a la perfección todo:

    Original:
    $IP route add table $TABLE_NAME default dev $WAN_PPPoE scope link
    Mi Caso:
    $IP route add table $TABLE_NAME default via 192.168.202.1 dev $WAN_PPPoE

    Luego solo he tenido que ir añadiendo las marcas de paquetes con diferente numeración para el resto de ADSL y añadiendo la ruta en la tabla correspondiente.

    Lo dejo aquí por si alguien en un futuro le pasa lo mismo.

    Un saludo,
    david

  • Marcos, antes que nada quisiera agradecerte por tu aporte, me ha servido de mucho.
    Quisiera compartir mi experiencia por si a alguien más le sirve.

    Implementé la solución en un CentOS 5.7 y un fwbuilder 5.0.1.3592.

    El FWB 5.0.1 difiere en algunos detalles respecto al 4.0.x.
    A la primer regla del firewall le puse en “Action” la opción “continue”, y en opciones si el TagPPPoE.

    Y en “Host OS Settings > Options > Kernel anti-spoofing protection” tuve que especificarle “Off” para que me funcionara.

    Tengo que ver que implicancias del punto de vista de seguridad tiene aparejado este “Off”.
    Asi que por ahora Up&Running.

    Gracias/Saludos

    Ariel

  • Roosje

    Hi Marcos,
    I am apologizing for the lengthy reply.
    I have such a setup with the right rules and markings. I see with tcpdump that the packets are routed correctly and get back from the website I am trying to access, but aren’t routed back to the PC on the LAN.
    I have the Kernel anti-spoofing set to Off and it still doesn’t work for me.
    I have two ISP connections.
    My default ISP is on eth2 and the secondary one is on eth1. Both are fixed IP address and they both work OK.
    These are my interfaces (partial output):
    3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 202.202.202.27/26 brd 202.202.202.63 scope global eth1
    4: eth2: mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 180.180.180.194/30 brd 180.180.180.195 scope global eth2

    Main routing table:
    [root@myserver ~]# ip route show table main
    180.180.180.192/30 dev eth2 proto kernel scope link src 180.180.180.194
    202.202.202.0/26 dev eth1 proto kernel scope link src 202.202.202.27
    192.168.7.0/24 dev br0 proto kernel scope link src 192.168.7.11
    192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.11
    192.168.17.0/24 dev eth3.10 proto kernel scope link src 192.168.17.1
    192.168.77.0/24 dev eth3 proto kernel scope link src 192.168.77.1
    192.168.27.0/24 dev eth3.11 proto kernel scope link src 192.168.27.1
    default via 180.180.180.193 dev eth2

    Routing table for IPS2:
    [root@myserver ~]# ip route show table ISP2
    180.180.180.192/30 dev eth2 proto kernel scope link src 180.180.180.194
    202.202.202.0/26 dev eth1 proto kernel scope link src 202.202.202.27
    192.168.7.0/24 dev br0 proto kernel scope link src 192.168.7.11
    192.168.17.0/24 dev eth3.10 proto kernel scope link src 192.168.17.1
    192.168.77.0/24 dev eth3 proto kernel scope link src 192.168.77.1
    192.168.27.0/24 dev eth3.11 proto kernel scope link src 192.168.27.1
    default dev eth1 scope link

    Ip rule when the iprules script if Off:
    [root@myserver ~]# ip rule show
    0: from all lookup local
    32766: from all lookup main
    32767: from all lookup default

    Ip rule when the iprules script if On (TABLE_NAME in script is ISP2:
    [root@myserver ~]# ip rule show
    0: from all lookup local
    32765: from all fwmark 0x4 lookup ISP2
    32766: from all lookup main
    32767: from all lookup default

    My tcpdump command is use on both cases below:
    tcpdump -i any tcp and \(dst net 212.212.212.202/32 or src net 212.212.212.202/32\) -nnvXSs 0 -c12

    In the tcpdump results below I ommit packet information not relevant to the case.

    This is what I get from tcpdump when I run in “normal” mode (routing everything through ISP-1[eth2]). This goes OK!:
    tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    08:39:14.368974 IP (tos 0x0, ttl 128, id 20346, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [S], cksum 0xc166 (correct), seq 2601385814, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:39:14.368974 IP (tos 0x0, ttl 128, id 20346, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [S], cksum 0xc166 (correct), seq 2601385814, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:39:14.369099 IP (tos 0x0, ttl 127, id 20346, offset 0, flags [DF], proto TCP (6), length 52)
    180.180.180.194.50733 > 212.212.212.202.80: Flags [S], cksum 0x3c4c (correct), seq 2601385814, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:39:14.507800 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 180.180.180.194.50733: Flags [S.], cksum 0xf365 (correct), seq 3719263312, ack 2601385815, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    This one is what I miss in “iprules” mode below. This packet has been de-SNAT-ted and is now sent to the PC.
    08:39:14.507829 IP (tos 0x0, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 192.168.7.2.50733: Flags [S.], cksum 0x7880 (correct), seq 3719263312, ack 2601385815, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    08:39:14.507836 IP (tos 0x0, ttl 49, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 192.168.7.2.50733: Flags [S.], cksum 0x7880 (correct), seq 3719263312, ack 2601385815, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    08:39:14.508860 IP (tos 0x0, ttl 128, id 20348, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [.], cksum 0x8ff9 (correct), ack 3719263313, win 16425, length 0
    Hex display of packet ….
    08:39:14.508860 IP (tos 0x0, ttl 128, id 20348, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [.], cksum 0x8ff9 (correct), ack 3719263313, win 16425, length 0
    Hex display of packet ….
    08:39:14.508885 IP (tos 0x0, ttl 127, id 20348, offset 0, flags [DF], proto TCP (6), length 40)
    180.180.180.194.50733 > 212.212.212.202.80: Flags [.], cksum 0x0adf (correct), ack 3719263313, win 16425, length 0
    Hex display of packet ….
    08:39:14.508933 IP (tos 0x0, ttl 128, id 20349, offset 0, flags [DF], proto TCP (6), length 440)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [P.], cksum 0x59b3 (correct), seq 2601385815:2601386215, ack 3719263313, win 16425, length 400
    Data etc. etc. etc.
    08:39:14.508933 IP (tos 0x0, ttl 128, id 20349, offset 0, flags [DF], proto TCP (6), length 440)
    192.168.7.2.50733 > 212.212.212.202.80: Flags [P.], cksum 0x59b3 (correct), seq 2601385815:2601386215, ack 3719263313, win 16425, length 400
    Data etc. etc. etc.
    08:39:14.508951 IP (tos 0x0, ttl 127, id 20349, offset 0, flags [DF], proto TCP (6), length 440)
    180.180.180.194.50733 > 212.212.212.202.80: Flags [P.], cksum 0xd498 (correct), seq 2601385815:2601386215, ack 3719263313, win 16425, length 400
    Data etc. etc. etc.
    12 packets captured
    12 packets received by filter
    0 packets dropped by kernel

    This is what I get from tcpdump when I run in “iprules” mode (routing everything through ISP-2[eth1]). This does not send the packets to the PC (192.168.7.2)!:
    tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    08:45:01.833462 IP (tos 0x0, ttl 128, id 22650, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xd934 (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:01.833462 IP (tos 0x0, ttl 128, id 22650, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xd934 (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:01.833584 IP (tos 0x0, ttl 127, id 22650, offset 0, flags [DF], proto TCP (6), length 52)
    202.202.202.27.50766 > 212.212.212.202.80: Flags [S], cksum 0xc06b (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    This is the reply from the web server on the web. So far so good:
    08:45:01.991616 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 202.202.202.27.50766: Flags [S.], cksum 0x269f (correct), seq 2345211677, ack 3515658473, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    The packet above isn’t being de-SNAT-ed, so-to-speak.
    This is the PC trying again, because it did not get a reply:
    08:45:04.822252 IP (tos 0x0, ttl 128, id 22684, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xd934 (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:04.822252 IP (tos 0x0, ttl 128, id 22684, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xd934 (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:04.822277 IP (tos 0x0, ttl 127, id 22684, offset 0, flags [DF], proto TCP (6), length 52)
    202.202.202.27.50766 > 212.212.212.202.80: Flags [S], cksum 0xc06b (correct), seq 3515658472, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
    Hex display of packet ….
    This is the reply from the web server on the web (again) … and so it goes on:
    08:45:04.980048 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 202.202.202.27.50766: Flags [S.], cksum 0x269f (correct), seq 2345211677, ack 3515658473, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    08:45:05.547934 IP (tos 0x0, ttl 50, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    212.212.212.202.80 > 202.202.202.27.50766: Flags [S.], cksum 0x269f (correct), seq 2345211677, ack 3515658473, win 5840, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    Hex display of packet ….
    08:45:10.822254 IP (tos 0x0, ttl 128, id 22779, offset 0, flags [DF], proto TCP (6), length 48)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xed3d (correct), seq 3515658472, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:10.822254 IP (tos 0x0, ttl 128, id 22779, offset 0, flags [DF], proto TCP (6), length 48)
    192.168.7.2.50766 > 212.212.212.202.80: Flags [S], cksum 0xed3d (correct), seq 3515658472, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    Hex display of packet ….
    08:45:10.822277 IP (tos 0x0, ttl 127, id 22779, offset 0, flags [DF], proto TCP (6), length 48)
    202.202.202.27.50766 > 212.212.212.202.80: Flags [S], cksum 0xd474 (correct), seq 3515658472, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    Hex display of packet ….
    12 packets captured
    12 packets received by filter
    0 packets dropped by kernel

    NOTE:
    I replaced the first three octets of all my public IP addresses with dummy ones. That doesn’t impact my case though.

    IPTables sets this when you select Kernel anti-spoofing Off:
    [root@myserver ~]# cat /proc/sys/net/ipv4/conf/all/rp_filter
    0

    Info:
    I also have the Continue Action as indicated by Ariel Pereira.

    Maybe you can help with this.

    Regards,

    Roosje

  • Roosje

    Hi Marcos,
    I solved the problem.
    The thing is, I had to disable the rp_filter for each interface individually and manually.
    FWBuilder does not do that for you. it sets the global setting, which does not change individual interfaces if the default is set otherwise (see below).
    I got a hint from this these links:
    http://www.tolaris.com/2009/07/13/disabling-reverse-path-filtering-in-complex-networks/
    http://blog.yibi.org/2012/01/05/reverse-path-filtering-in-rhel-6

    .. and I did it this way:
    I added these two lines to my /etc/sysctl.conf file and rebooted:
    net.ipv4.conf.eth0.rp_filter = 0
    net.ipv4.conf.eth1.rp_filter = 0

    … even though this line was already in /etc/sysctl.conf:
    net.ipv4.conf.default.rp_filter = 1
    (means other interfaces are set to 1)

    I first tested it by executing:
    echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
    echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

    No other thing to set. It worked immediately!

    I am not sure I really needed to disable it on my internal interface (eth0). I will have to test that.

    Documentation of rp_filter values can be found at: http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

    I see that my previous comment was still awaiting moderation, but you may add parts of this writing to your article.
    I was working on CentOS 6.2 and, as one of the links says, it has those settings on by default.

    Also:
    You may change your article:
    With FWBuilder 5.0.x you a A) first rule with Continue as Action and with the Tag and B) one rule following that one with Accept.

    Thanks. It was a good article.

    Roosje

  • Henry

    Buenas,
    Muchas gracias por la información, me ayudo a la perfección,

    Un saludo,
    Henry

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>