Dear All
I'm trying to configure iptables with Network Address Translation
Scenario is like
server 1 with IP address 192.168.131.131 is running httpd
server 2 with two NIC, one is xx.xx.xx.xx ( live ip ) and another is 192.168.131.133,
--- I run following command on server 2 ( which is going to be acting as firewall )
iptables -t NAT -A PREROUTING -d xx.xx.xx.xx -J DNAT --to-destination 192.168.131.131
but it ends with following error
iptables v1.3.5: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.
----------Following are some details of my server-------- *uname -r *
2.6.18-194.32.1.el5
*lsmod | grep ip *
ip_tables 17029 0 x_tables 17349 1 ip_tables ipv6 270561 19 xfrm_nalgo 13381 1 ipv6 acpiphp 27089 0 dm_multipath 25421 0 scsi_dh 12097 1 dm_multipath dm_mod 63225 15 dm_multipath,dm_raid45,dm_snapshot,dm_zero,dm_mirror,dm_log
Can anyone guide me ??? whats going wrong with it ? how to resolve this problem
Thanx & regards
Jatin K <ssh.fedora <at> gmail.com> writes:
... Dear All I'm trying to configure iptables with Network Address Translation ... iptables v1.3.5: can’t initialize iptables table `nat’: Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.
On F14.
Kernel configuration: $ less /boot/config-* search for NAT
If configured as modules, see kernel modules: $ less /lib/modules/2.6.*/modules.dep search for nat (or nf_nat)
Test: # modprobe nf_nat
Other config files: # less /etc/sysconfig/iptables-config
Also /proc fs.
JB
On Tuesday 25 January 2011 05:07 PM, Jorge Fábregas wrote:
On 01/25/2011 06:15 AM, Jatin K wrote:
iptables -t NAT -A PREROUTING -d xx.xx.xx.xx -J DNAT --to-destination 192.168.131.131
but it ends with following error
Hi,
The names of the tables are case-sensitive. It should be nat instead of NAT.
HTH, JOrge
Thnx
I'got your point replaced NAT with nat ... saved iptables wiht service iptable save
but server is not forwarding the packets to the web server
if i try http://xx.xx.xx.xx ( live ip ) .. .. no page is displayed
what it could be ???
On 01/25/2011 08:17 AM, Jatin K wrote:
but server is not forwarding the packets to the web server
Besides the NAT rule, you'll need a forward rule (as that traffic is not for the machine hosting the firewall). I think you'll need something like:
iptables -A FORWARD -d 192.168.131.131 -p tcp --dport 80 -j ACCEPT
...and of course check the firewall on the web-server to allow incoming TCP/80.
-- Jorge
Hi ,
On the server where you have the web page you have iptables up and blocking the 80 port ? the service is up and running ? it's accepting connection from all interfaces , not only on localhost ?
On Tue, Jan 25, 2011 at 2:17 PM, Jatin K ssh.fedora@gmail.com wrote:
On Tuesday 25 January 2011 05:07 PM, Jorge Fábregas wrote:
On 01/25/2011 06:15 AM, Jatin K wrote:
iptables -t NAT -A PREROUTING -d xx.xx.xx.xx -J DNAT --to-destination 192.168.131.131
but it ends with following error
Hi,
The names of the tables are case-sensitive. It should be nat instead of NAT.
HTH, JOrge
Thnx
I'got your point replaced NAT with nat ... saved iptables wiht service iptable save
but server is not forwarding the packets to the web server
if i try http://xx.xx.xx.xx ( live ip ) .. .. no page is displayed
what it could be ???
-- °v° /(_)\ ^ ^ Jatin Khatri Registerd Linux user No #501175 www.counter.li.org No M$
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
On Tuesday 25 January 2011 06:16 PM, Jorge Fábregas wrote:
On 01/25/2011 08:17 AM, Jatin K wrote:
but server is not forwarding the packets to the web server
Besides the NAT rule, you'll need a forward rule (as that traffic is not for the machine hosting the firewall). I think you'll need something like:
iptables -A FORWARD -d 192.168.131.131 -p tcp --dport 80 -j ACCEPT
...and of course check the firewall on the web-server to allow incoming TCP/80.
-- Jorge
I've done the following
[1] echo 1 > /proc/sys/net/ipv4/ip_forward ( enabled ip forwarding )
[2] iptables -A FORWARD -d 192.168.131.131 -p tcp --dport 80 -j ACCEPT
[3] iptables -t nat -A PREROUTING -d xx.xx.xx.xx -p tcp --dport 80 -j DNAT --to-destination 192.168.131.131
port 80 is opened on the web server I'm able to access the web -page from internal systems as well as from the firewall it self through elinks but not able to access the web-page from Internet ( means firewall system is not forwarding the packets to the web server )
I've also tried following rule in firewall for SNAT
iptables -t nat -A POSTROUTING -s 192.168.131.131 -j SNAT --to-source xx.xx.xx.xx
but it fails
what do I need to check further .... what other configuration do I need ??
Thnx
On Tue, 2011-01-25 at 17:47 +0530, Jatin K wrote:
I'got your point replaced NAT with nat ... saved iptables wiht service iptable save
but server is not forwarding the packets to the web server
if i try http://xx.xx.xx.xx ( live ip ) .. .. no page is displayed
what it could be ???
To test the NAT rule, you'd have to make an incoming connection through that network. You could use an outside proxy. Or, you could go to one of the HTML validator sites, and ask it to validate your homepage. That's a simple check, without having to set up anything special.
e.g. Visit http://validator.w3.org/ and give it the address to your website (your IP address that you've not being telling us).
On Tuesday 25 January 2011 07:08 PM, Tim wrote:
On Tue, 2011-01-25 at 17:47 +0530, Jatin K wrote:
I'got your point replaced NAT with nat ... saved iptables wiht service iptable save
but server is not forwarding the packets to the web server
if i try http://xx.xx.xx.xx ( live ip ) .. .. no page is displayed
what it could be ???
To test the NAT rule, you'd have to make an incoming connection through that network. You could use an outside proxy. Or, you could go to one of the HTML validator sites, and ask it to validate your homepage. That's a simple check, without having to set up anything special.
e.g. Visit http://validator.w3.org/ and give it the address to your website (your IP address that you've not being telling us).
I've tested this function through other ISP ( from my other branch ) .... and also checked it from my phone on 3G network
On Tue, 2011-01-25 at 19:33 +0530, Jatin K wrote:
I've tested this function through other ISP ( from my other branch ) .... and also checked it from my phone on 3G network
Then, you've got several things to think about:
Firewall. Is it getting in the way, before or after the NAT rule?
Is there something before your computer (e.g. a modem/router)? Does it need configuring to let it through.
Is your webserver listening for connections on all interfaces?
Once you get it going, I'd go back and refine your NAT rule. Do you want all ports to be NATed through, or just port 80?
By way of example, I've just copied (below) a few rules that I have on an old Fedora box, back from when I was using dial-up. Those narrowed down connections to only TCP, particular TCP port numbers, particular interfaces, and/or particular source addresses.
iptables --table nat --append PREROUTING --protocol tcp --destination-port 80 --jump DNAT --to-destination 192.168.1.1:80
iptables --table nat --append PREROUTING --protocol tcp --in-interface ppp+ --source 2.3.4.5 --destination-port 80 --jump DNAT --to-destination 192.168.1.1:80
iptables --table nat --append PREROUTING --protocol tcp --in-interface ppp+ --source 0.0.0.0/0 --destination-port 443 --jump DNAT --to-destination 192.168.1.6:443
What is the default gateway on the web server? It's possible that packets are getting through the "gateway" server just fine, but getting lost on the way back.
On Tuesday, January 25, 2011 09:12:07 am Ian Pilcher wrote:
What is the default gateway on the web server? It's possible that packets are getting through the "gateway" server just fine, but getting lost on the way back.
Can the OP run wireshark and look for the packets?
Also, if one does iptables -L -v -t nat -and- iptables -L -v before and after trying to send a packet from the Internet to his server, do the byte and packet counts for the nat iptables entries and the other iptables entries (for forwarding the packet) get incremented as expected?
On Tuesday 25 January 2011 08:13 PM, Tim wrote:
On Tue, 2011-01-25 at 19:33 +0530, Jatin K wrote:
I've tested this function through other ISP ( from my other branch ) .... and also checked it from my phone on 3G network
Then, you've got several things to think about:
Firewall. Is it getting in the way, before or after the NAT rule?
Is there something before your computer (e.g. a modem/router)? Does it need configuring to let it through.
yes there is ADSL router ..... which forwards port 80 from wan to lan 80 ( means to port 80 on firewall )
setup is like ADSL----> NIC 1 of firewall NIC 2 connects to the webserver
if any request arrives to live ip on ADSL Router it sends it to the firewall ( I've tested it by running httpd on firewall and it works fine )
Is your webserver listening for connections on all interfaces?
yes
Once you get it going, I'd go back and refine your NAT rule. Do you want all ports to be NATed through, or just port 80?
I just want only port 80 to be NATed ( if request arrives on port 80 on my live ip it should be nated to the entire webserver through firewall )
By way of example, I've just copied (below) a few rules that I have on an old Fedora box, back from when I was using dial-up. Those narrowed down connections to only TCP, particular TCP port numbers, particular interfaces, and/or particular source addresses.
iptables --table nat --append PREROUTING --protocol tcp --destination-port 80 --jump DNAT --to-destination 192.168.1.1:80
I've done the same thing like you said
iptables -t nat -A PREROUTING -d xx.xx.xx.xx -t tpc --dport 80 -j DNAT --to-destination 192.168.131.131
iptables --table nat --append PREROUTING --protocol tcp --in-interface ppp+ --source 2.3.4.5 --destination-port 80 --jump DNAT --to-destination 192.168.1.1:80
iptables --table nat --append PREROUTING --protocol tcp --in-interface ppp+ --source 0.0.0.0/0 --destination-port 443 --jump DNAT --to-destination 192.168.1.6:443
On Wed, 2011-01-26 at 01:13 +1030, Tim wrote:
Then, you've got several things to think about:
Another one: Does your ISP block remote access to port 80.
I forgot about that, lots of ISPs do that.
On Tuesday 25 January 2011 10:44 PM, Tim wrote:
On Wed, 2011-01-26 at 01:13 +1030, Tim wrote:
Then, you've got several things to think about:
Another one: Does your ISP block remote access to port 80.
no they do not .... I'm very sure about that
I forgot about that, lots of ISPs do that.
On Tuesday, January 25, 2011 02:26:02 pm Tim did opine:
On Wed, 2011-01-26 at 01:13 +1030, Tim wrote:
Then, you've got several things to think about:
Another one: Does your ISP block remote access to port 80.
I forgot about that, lots of ISPs do that.
Which is why I have a :85 in my web pages address.
On Tuesday, January 25, 2011 02:28:15 pm Jatin K did opine:
On Tuesday 25 January 2011 10:44 PM, Tim wrote:
On Wed, 2011-01-26 at 01:13 +1030, Tim wrote:
Then, you've got several things to think about:
Another one: Does your ISP block remote access to port 80.
no they do not .... I'm very sure about that
It is far more common than the uninformed "experts" such as you think. They block only the incoming port 80's so that if Joe & Judy Lunchbucket want a web page, they have to use the ISP's servers, which the ISP then wraps in advertising for additional revenue.
Don't believe it?, then try http://gene.homelinux.net/gene Nothing, it is blocked. No ISP will admit to it because it would cost them their 'common carrier' status at the FCC. I'll leave it to you to figure out how to get around that block. There is a machine there, this one.
I forgot about that, lots of ISPs do that.
On 01/25/2011 01:13 PM, Jatin K wrote:
iptables -t nat -A PREROUTING -d xx.xx.xx.xx -t tpc --dport 80 -j DNAT --to-destination 192.168.131.131
Ok, assuming your default policy is to drop, I think you'll need this rule:
iptables -A FORWARD -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
I'm assuming eth1 is your internal interface (and eth0 your external WAN iface). This rule will allow the responses from your web-server to pass-thru your firewal...
Also, if you leave all like this it won't work as you need to perform "Source NAT or Masquerade" for your 192.168.131.131 ip (if you don't...then it will leave your external interface as coming from 192.168.131.131 which of course is not valid ip for the internet). In order for your webserver send responses to a machine on the internet you need to masquerade its ip. You can do this with this:
iptables -A POSTROUTING -o eth0 -s 192.168.131.0/24 -j MASQUERADE
That is, all traffic that will go out thru eth0, if the source network is 192.168.131.0/24, then change the source ip to that of your eth0 (your WAN ip).
Try that and see if works.
HTH, Jorge
On 01/25/2011 11:36 AM, Gene Heskett wrote:
They block only the incoming port 80's so that if Joe& Judy Lunchbucket want a web page, they have to use the ISP's servers, which the ISP then wraps in advertising for additional revenue.
Or do what I do: host it at a third-party webhosting service.
On Tuesday, January 25, 2011 08:40:02 pm Joe Zeff did opine:
On 01/25/2011 11:36 AM, Gene Heskett wrote:
They block only the incoming port 80's so that if Joe& Judy Lunchbucket want a web page, they have to use the ISP's servers, which the ISP then wraps in advertising for additional revenue.
Or do what I do: host it at a third-party webhosting service.
Which still leaves it far more difficult to control. Its mine, the pix are mine and it all disappears if I want it to.
On Tue, 2011-01-25 at 22:43 +0530, Jatin K wrote:
setup is like ADSL----> NIC 1 of firewall NIC 2 connects to the webserver
if any request arrives to live ip on ADSL Router it sends it to the firewall ( I've tested it by running httpd on firewall and it works fine )
Okay, I've done something similar in the past:
dial-up modem to gateway box (firewall and NAT), with a webserver on another box further inside the LAN.
Looking through my old firewall configuration file, I had, on the firewall:
default input rules set to drop default output rules set to allow input accept rule for this traffic temporary input log rule for this traffic (for debugging) input nat table prerouting rule for this traffic input accept state rule for established & related temporary input log state rule for established & related
And, on the internal webserver:
default input rules set to drop default output rules set to allow input accept rule for this traffic input accept state rule for established & related
You can play around with putting log rules ahead of your accept and redirect rules, to see attempts that may or may not get through. And log rules after them, to show what did get through.
And, since you're playing with NAT, the end of the firewall rule script would have something like:
iptables --table nat --append POSTROUTING --out-interface ppp+ --jump MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward
It's been a hell of a long time since I've had to do this, but I suspect your problem may be to do with firewall rules on the web server box, inside your LAN. External IP addresses disallowed through the LAN interface, perhaps?
These days I do it all on the modem/router. Its firewall is up. It only allows through a webserver on occasions I'm temporarily running one (with a forwarding rule on the modem/router). All the client computers run their own firewalls.
My public website is hosted externally. Where *they* have to deal with spam, security, uptime. And I don't have to keep a permanent IP, nor permanently running computer.
On Wednesday 26 January 2011 04:44 AM, Jorge Fábregas wrote:
On 01/25/2011 01:13 PM, Jatin K wrote:
iptables -t nat -A PREROUTING -d xx.xx.xx.xx -t tpc --dport 80 -j DNAT --to-destination 192.168.131.131
Ok, assuming your default policy is to drop, I think you'll need this rule:
iptables -A FORWARD -i eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
I'm assuming eth1 is your internal interface (and eth0 your external WAN iface). This rule will allow the responses from your web-server to pass-thru your firewal...
Also, if you leave all like this it won't work as you need to perform "Source NAT or Masquerade" for your 192.168.131.131 ip (if you don't...then it will leave your external interface as coming from 192.168.131.131 which of course is not valid ip for the internet). In order for your webserver send responses to a machine on the internet you need to masquerade its ip. You can do this with this:
iptables -A POSTROUTING -o eth0 -s 192.168.131.0/24 -j MASQUERADE
I've not tried this .... thanx for suggestion
I will try it and let the list know
That is, all traffic that will go out thru eth0, if the source network is 192.168.131.0/24, then change the source ip to that of your eth0 (your WAN ip).
Try that and see if works.
HTH, Jorge
On Wednesday 26 January 2011 01:06 AM, Gene Heskett wrote:
On Tuesday, January 25, 2011 02:28:15 pm Jatin K did opine:
On Tuesday 25 January 2011 10:44 PM, Tim wrote:
On Wed, 2011-01-26 at 01:13 +1030, Tim wrote:
Then, you've got several things to think about:
Another one: Does your ISP block remote access to port 80.
no they do not .... I'm very sure about that
It is far more common than the uninformed "experts" such as you think. They block only the incoming port 80's so that if Joe& Judy Lunchbucket want a web page, they have to use the ISP's servers, which the ISP then wraps in advertising for additional revenue.
I previously said that ..if I remove the firewall ....all the things works fine ... without any problem
I don't think there is any problem regarding my ISP
BTW .. I surprised that this kind of things/action can be take by the ISP
Don't believe it?, then tryhttp://gene.homelinux.net/gene Nothing, it is blocked. No ISP will admit to it because it would cost them their 'common carrier' status at the FCC. I'll leave it to you to figure out how to get around that block. There is a machine there, this one.
I forgot about that, lots of ISPs do that.
On Wed, 2011-01-26 at 21:27 +0530, Jatin K wrote:
I surprised that this kind of things/action can be take by the ISP
Over here, in Australia...
Some ISPs block port 80 by default, though you may enable it. I seem to recall that was an ISP-reaction to a worm.
Some ISPs block port 80, unless you pay extra for a business account. Partially as a way for them to get more money out of you, partially because their usual consumer configuration is designed more for traffic flowing in the other direction.
On Wednesday 26 January 2011 10:21 PM, Tim wrote:
On Wed, 2011-01-26 at 21:27 +0530, Jatin K wrote:
I surprised that this kind of things/action can be take by the ISP
Over here, in Australia...
Some ISPs block port 80 by default, though you may enable it. I seem to recall that was an ISP-reaction to a worm.
Dear all
I've got it working and it works like anything ...
This[1] is the output of command service iptables status
---------[1]----------------------------------------------------------
Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 DNAT all -- 0.0.0.0/0 xx.xx.xx.xx tcp dpt:80 to:192.168.131.131:80 2 DNAT all -- 0.0.0.0/0 192.168.131.133 tcp dpt:80 to:192.168.131.131:80
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE all -- 192.168.131.131/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination
Chain FORWARD (policy ACCEPT) num target prot opt source destination
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
On Fri, 2011-01-28 at 10:41 +0530, Jatin K wrote:
I've got it working and it works like anything ...
This[1] is the output of command service iptables status
---------[1]----------------------------------------------------------
Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 DNAT all -- 0.0.0.0/0 xx.xx.xx.xx tcp dpt:80 to:192.168.131.131:80 2 DNAT all -- 0.0.0.0/0 192.168.131.133 tcp dpt:80 to:192.168.131.131:80
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE all -- 192.168.131.131/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination
Chain FORWARD (policy ACCEPT) num target prot opt source destination
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Is that the entire output? Because, unless there's something else that's not shown above, you have no firewall. Everything's accepted.
On Friday 28 January 2011 02:00 PM, Tim wrote:
On Fri, 2011-01-28 at 10:41 +0530, Jatin K wrote:
I've got it working and it works like anything ...
This[1] is the output of command service iptables status
---------[1]----------------------------------------------------------
Table: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination 1 DNAT all -- 0.0.0.0/0 xx.xx.xx.xx tcp dpt:80 to:192.168.131.131:80 2 DNAT all -- 0.0.0.0/0 192.168.131.133 tcp dpt:80 to:192.168.131.131:80
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE all -- 192.168.131.131/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination
Chain FORWARD (policy ACCEPT) num target prot opt source destination
Chain OUTPUT (policy ACCEPT) num target prot opt source destination
Is that the entire output?
yes it is
Because, unless there's something else that's not shown above, you have no firewall. Everything's accepted.
On 01/28/2011 01:11 AM, Jatin K wrote:
um target prot opt source destination 2 DNAT all -- 0.0.0.0/0 192.168.131.133 tcp dpt:80 to:192.168.131.131:80
This line doesn't look right. Is it doing DNAT For the host 192.168.131.133 (converting it to 192.168.131.131? This doesn't make sense as 192.168.131.133 belongs to your internal network.
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE all -- 192.168.131.131/24 0.0.0.0/0
192.168.131.131/24 is incorrect. If it's a particular host it should be 192.168.131.131/32 or simply 192.168.131.131. If it's for the network then it would be 192.168.131.0/24 (proper way to specify network).
And again, just like Tim mentioned, you're not firewalling anything. At this point you're just basically routing & NATing.
HTH, Jorge
On Fri, 2011-01-28 at 15:31 +0530, Jatin K wrote:
yes it is
Is there a device ahead of this that is firewalling?
Because if you're providing a website accessible to the public, there's no doubt that someone will try to hack you.
If you were doing what was discussed earlier on (putting in access and prerouting rules, to the webserver), and /that/ worked. Then changing your input policy to drop, gives you firewalling (i.e. deny everything, except the specify exception rules you put in).
On Friday 28 January 2011 07:42 PM, Tim wrote:
On Fri, 2011-01-28 at 15:31 +0530, Jatin K wrote:
yes it is
Is there a device ahead of this that is firewalling?
yes there is a linksys ADSL router ( with basic firewall ....with only port 80 is maped to internal port 80 )
Because if you're providing a website accessible to the public, there's no doubt that someone will try to hack you.
basically that web server will be accessed by our remote branches users ( actually the web server is win2k3, our core application is published on it through IIS )
If you were doing what was discussed earlier on (putting in access and prerouting rules, to the webserver), and /that/ worked. Then changing your input policy to drop, gives you firewalling (i.e. deny everything, except the specify exception rules you put in).
there are some policy for internal networks as well ... between the internal office department ( some departments on different subnets )
I've posted some part of iptables status ( to shorten the mail ) , there are some more policies , and at the end everything is rejected.
Thnx Tim and all others for you input and suggestions
On Friday 28 January 2011 04:37 PM, Jorge Fábregas wrote:
On 01/28/2011 01:11 AM, Jatin K wrote:
um target prot opt source destination 2 DNAT all -- 0.0.0.0/0 192.168.131.133 tcp dpt:80 to:192.168.131.131:80
This line doesn't look right. Is it doing DNAT For the host 192.168.131.133 (converting it to 192.168.131.131? This doesn't make sense as 192.168.131.133 belongs to your internal network.
that is corrected now ...... I came to know littlebit later
Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 MASQUERADE all -- 192.168.131.131/24 0.0.0.0/0
192.168.131.131/24 is incorrect. If it's a particular host it should be 192.168.131.131/32 or simply 192.168.131.131. If it's for the network then it would be 192.168.131.0/24 (proper way to specify network).
Wow .... that I did not think about .... it must be only one host 192.168.131.131 ... I will correct it
And again, just like Tim mentioned, you're not firewalling anything. At this point you're just basically routing& NATing.
HTH, Jorge
Thank you very much Jorge
have a good day
-
Dan Catana -
Gene Heskett -
Ian Pilcher -
Jatin K -
JB -
Joe Zeff -
Jorge Fábregas -
Richard Sewill -
Tim