Topic: OpenVPN: let only one LAN ip use the tun0

The content of this topic has been archived on 9 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

Nikotine

1 Apr 2013, 18:46

Hi,

I have a TP-Link 1043nd running Barrier Breaker r36139.
OpenVPN is installed and running.

I start OpenVPN using this line in rc.local:

/usr/sbin/openvpn --cd /etc/openvpn --daemon --config /etc/openvpn/mullvad_linux.conf &

What currently happens is that all network traffic is routed through tun0. I want my normal network traffic to go through the normal WAN, my ISP's ip address. Only one LAN ip (and preferably only certain ports e.g. 192.168.1.3:1234) should go through tun0.
How do I configure that?

This is my network file:

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth0.1'
    option type 'bridge'
    option proto 'static'
    option ipaddr '192.168.1.1'
    option netmask '255.255.255.0'

config interface 'wan'
    option ifname 'eth0.2'
    option type 'bridge'
    option _orig_ifname 'eth0.2'
    option _orig_bridge 'true'
    option proto 'dhcp'
    option peerdns '0'
    option dns '8.8.8.8 8.8.4.4'

config switch
    option reset '1'
    option enable_vlan '1'
    option name 'switch0'

config switch_vlan
    option vlan '1'
    option ports '1 2 3 4 5t'
    option device 'switch0'

config switch_vlan
    option vlan '2'
    option ports '0 5t'
    option device 'switch0'

config interface 'vpn_interface'
    option proto 'none'
    option ifname 'tun0'
    option auto '1'

This is my firewall file:

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option src_ip 'fe80::/10'
    option src_port '547'
    option dest_ip 'fe80::/10'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option network 'lan'

config zone
    option name 'wan'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'
    option network 'wan'

config include
    option path '/etc/firewall.user'

config redirect
    option target 'DNAT'
    option src 'wan'
    option dest 'lan'
    option proto 'tcp udp'
    option src_dport '9091'
    option dest_ip '192.168.1.3'
    option dest_port '9091'
    option name 'NAS bittorrent webUI'

config redirect
    option target 'DNAT'
    option src 'wan'
    option dest 'lan'
    option proto 'tcp udp'
    option src_dport '2222'
    option dest_ip '192.168.1.3'
    option dest_port '2222'
    option name 'NAS SSH'

config redirect
    option target 'DNAT'
    option src 'wan'
    option dest 'lan'
    option proto 'tcp udp'
    option src_dport '1723'
    option dest_port '1723'
    option name 'NAS bittorrent poort'
    option dest_ip '192.168.1.3'

config forwarding
    option dest 'wan'
    option src 'lan'

config zone
    option name 'vpn_zone'
    option masq '1'
    option network 'vpn_interface'
    option output 'ACCEPT'
    option input 'ACCEPT'
    option forward 'ACCEPT'

config forwarding
    option dest 'lan'
    option src 'vpn_zone'

config forwarding
    option dest 'vpn_zone'
    option src 'lan'

Post #2

zhadoom

1 Apr 2013, 23:54

Try this:

iptables -I FORWARD -i br-lan -o tun0 -j REJECT
iptables -I FORWARD -s 192.168.1.3/32 -o tun0 -j ACCEPT

Only forward packets from 192.168.1.3 and br-lan.

If your aplication needs masquerading ( tunnel ip need to be masked ) use this:

iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

All assuming that the tunnel interface is 'tun0' .

(Last edited by zhadoom on 1 Apr 2013, 23:57)

Post #3

Nikotine

2 Apr 2013, 09:04

Thanks zhadoom.

I'm not used to working with iptables. I need to input these lines in /etc/firewall.user and reboot, right?
Won't these new rules coincide with the last three rules in my firewall file? Should I remove these?

config zone
    option name 'vpn_zone'
    option masq '1'
    option network 'vpn_interface'
    option output 'ACCEPT'
    option input 'ACCEPT'
    option forward 'ACCEPT'

config forwarding
    option dest 'lan'
    option src 'vpn_zone'

config forwarding
    option dest 'vpn_zone'
    option src 'lan'

(Last edited by Nikotine on 2 Apr 2013, 09:12)

Post #4

brontide

2 Apr 2013, 11:18

If the VPN link provides another default route you may want to acheive this via multiwan since it can be non trivial to deal with several default routes.

Post #5

Nikotine

2 Apr 2013, 20:33

I've added your three lines to Network > Firewall > Custom rules in Luci:

# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.

iptables -I FORWARD -i br-lan -o tun0 -j REJECT
iptables -I FORWARD -s 192.168.1.3/32 -o tun0 -j ACCEPT
iptables -t nat -I POSTROUTING -o tun0  -j MASQUERADE

But after a reboot, I've lost access to the internet.

I've looked up multiwan in the wiki, but can't seem to understand what it's for, other than balancing between multiple WANs.

Any more tips please?

(Last edited by Nikotine on 2 Apr 2013, 20:35)

Post #6

brontide

2 Apr 2013, 22:47

I suggested muntiwan because it helps to manage multiple internet connections, which is the situation you are in. You have two "default" routes out to the internet, one just happens to piggyback on the other.

iptables -I FORWARD -i br-lan -o tun0 -j REJECT  # FULL STOP, any traffic that might have been routed is stopped here.
iptables -I FORWARD -s 192.168.1.3/32 -o tun0 -j ACCEPT
iptables -t nat -I POSTROUTING -o tun0  -j MASQUERADE

The basic problem is you are not injecting the rules in the right spot to alter the forwarding decision. This is why I suggested multiwan, as it simplifies creating these rules. You would set a default rule to go out the regular internet and then one that matched the host->dest and make the wan rule point it to the tun0.

Post #7

Nikotine

3 Apr 2013, 17:43

I tried configuring multiwan. This is my situation right now:

Interfaces:

vpn_interface isn't connected in this image because I've disabled it for the moment.

Firewall:

Multiwan:

I've set default route to WAN and 192.168.1.3 to vpn_interface.
I've added VPN_interface above, but disabled all balancing and health checks.

Should this be correct, because it isn't working as it should. Either everyone in the lan uses the vpn, or I loose all internet connection all together.

Post #8

brontide

3 Apr 2013, 17:57

On the surface it looks correct, but I'm just not sure.

Did you fully remove your firewall.user rules?

What does your routing table look like?

Post #9

Nikotine

3 Apr 2013, 18:44

firewall.user is empty.
This is my routing table with vpn active but multiwan disabled:

root@OpenWrt-Beneden:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.8.0.81       128.0.0.0       UG    0      0        0 tun0
default         192.168.0.1     0.0.0.0         UG    0      0        0 br-wan
10.8.0.1        10.8.0.81       255.255.255.255 UGH   0      0        0 tun0
10.8.0.81       *               255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.8.0.81       128.0.0.0       UG    0      0        0 tun0
192.168.0.0     *               255.255.255.0   U     0      0        0 br-wan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
199.115.114.209 192.168.0.1     255.255.255.255 UGH   0      0        0 br-wan

This is it with vpn and multiwan enabled:

root@OpenWrt-Beneden:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 br-wan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

Definitely not right...

Post #10

brontide

3 Apr 2013, 21:53

No wonder with that crazy strage default route from OpenVPN. You might be better off not pulling routes and setting them up with a script when the tunnel comes up. Multiwan generalls expects real default rroutes, not this crazy split default route that you have.

Post #11

Nikotine

3 Apr 2013, 22:04

Which routes should I be expecting after multiwan has been enabled?

Btw, it's entirely OpenVPN who's making those weird routes. These are the routes without vpn nor multiwan:

root@OpenWrt-Beneden:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 br-wan
192.168.0.0     *               255.255.255.0   U     0      0        0 br-wan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan

(Last edited by Nikotine on 3 Apr 2013, 22:40)

Post #12

Nikotine

4 Apr 2013, 00:38

Correction of the above, on reading about setting up routes with openvpn, I understand now when you say "better off not pulling routes"... It's the vpn server (mullvad in my case) that's pushing these routes, right?
How do I prevent this from happening? I suppose I can't omit all those routes?

Post #13

brontide

4 Apr 2013, 01:43

The problem is that OpenVPN pushes out two /1 routes that have the effect of a default route but because it's more specific it will automatically override any existing default route. Etiher diable the def1 flag or setup the routes manually after the link comes up. You are combining the two /1 ( 128.0.0.0 ) into a regular default route.

You still need to pinup a route to the openvpn server via the wan default gw ( last route in the normal listing )

Post #14

brontide

4 Apr 2013, 02:05

I keep looking, found a few other people with similar issues, but no simple fix.

Post #15

vhrm

4 Apr 2013, 02:31

Interesting. (first off i haven't tried this myself, but i recently realized i should know more about VPNs because they really twist normal networking concerns and that's why i'm poking my nose in here).

From reading around, i think these routes may be a feature (not a bug) aimed at the security conscious to make sure that if the VPN tunnel drops their requests don't get leaked on the normal connection.

This thread: http://www.wilderssecurity.com/showthread.php?t=334940 has some guy saying he thinks he remembers seeing something in the mullvad gui about it. Do you see anything about extra secure tunneling that you can disable ?

edit:
looking more it looks like "GUI" means specifically their VPN client... but i still believe these routes are part of that kind of "leak prevention" strategy. Have you pinged mullvad to ask them if this is something that's controllable for your account ? and/or if they have a suggestion ?

(Last edited by vhrm on 4 Apr 2013, 02:42)

Post #16

metai

4 Apr 2013, 03:45

vhrm wrote:

From reading around, i think these routes may be a feature (not a bug) aimed at the security conscious to make sure that if the VPN tunnel drops their requests don't get leaked on the normal connection.

I could very well be completely wrong, but perhaps it's a simple redirect-gateway, either in the config file or pushed by the server, prompting the client to set up default routes through the vpn interface. This way the VPN would work "out of the box" for their clients because, let's face it, certainly not many of them would be able to set up individual routes.

Open your OpenVPN client config file. If you can't find a redirect-gateway line in there to delete, it means it gets pushed by the server, you could then try setting the route-nopull directive in the config file to ignore any routes the server pushes.

(Last edited by metai on 4 Apr 2013, 03:46)

Post #17

Nikotine

4 Apr 2013, 09:48

Thanks for the suggestions everyone!

This is my openvpn configuration file:

# Notice to Mullvad customers:
# 
# Apart from openvpn, you also need to install the
# package "resolvconf", available via apt, e.g.
#
# For those of you behind very restrictive firewalls,
# you can use our tunnels on tcp port 443, as well as
# on udp port 53.
client

dev tun

proto udp
#proto tcp

remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 443
#remote openvpn.mullvad.net 53
#remote se.mullvad.net # Servers in Sweden
#remote nl.mullvad.net # Servers in the Netherlands

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Try to preserve some state across restarts.
persist-key
persist-tun

# Enable compression on the VPN link.
comp-lzo

# Set log file verbosity.
verb 3

remote-cert-tls server

ping-restart 60

# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Parses DHCP options from openvpn to update resolv.conf
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf

ping 10

ca master.mullvad.net.crt
cert mullvad.crt
key mullvad.key

Note that I had to comment out these lines as OpenWRT hasn't got an update-resolv-conf script and OpenVPN wouldn't start without it being commented out:

# Parses DHCP options from openvpn to update resolv.conf
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf

metai wrote:

Open your OpenVPN client config file. If you can't find a redirect-gateway line in there to delete, it means it gets pushed by the server, you could then try setting the route-nopull directive in the config file to ignore any routes the server pushes.

Ok, I can try that. But which routes should I be manually adding then?

I like managing network related stuff in one place, the OpenWRT router, but it might be better to configure vpn on my nas box (which is at 192.168.1.3).

(Last edited by Nikotine on 4 Apr 2013, 11:08)

Post #18

Nikotine

4 Apr 2013, 15:31

Alright, I've been reading up about routing tables to better understand what I'm seeing when I do route -n. Man, I'm learning a lot these days :-)

So basically these are my default routes:

root@OpenWrt-Beneden:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 br-wan
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

After connection with my vpn provider (mullvad), these routes are pushed and added to the table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 br-wan
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

default         10.8.0.81       128.0.0.0       UG    0      0        0 tun0   #added
128.0.0.0       10.8.0.81       128.0.0.0       UG    0      0        0 tun0   #added
10.8.0.1        10.8.0.81       255.255.255.255 UGH   0      0        0 tun0   #added
10.8.0.81       0.0.0.0         255.255.255.255 UH    0      0        0 tun0   #added
199.115.114.209 192.168.0.1     255.255.255.255 UGH   0      0        0 br-wan #added

I've reordered them to better understand what's going on.
The first two newly added routes basically overwrite the default route that already exists, because it's more specific! This means all traffic is routed through tun0, which I don't want.

So what I want is that the first two lines aren't pushed. The other three added routes seem necessary ;-)
It appears that it's a server configuration called 'redirect-gateway' that is causing this.
As I don't own the server, I can't disable it.
I could add 'route-nopull' to the client config file, but that would also stop the last three routes being added and I need those.

Last possibility is using a script to remove the two routes after a vpn connection has been established.
Would this be a good script?

route del -net 0.0.0.0/1 gw xxx.xxx.xxx.xxx tun0 #in this case 10.8.0.81
route del -net 128.0.0.0/1 gw xxx.xxx.xxx.xxx tun0
route add -host 192.168.1.3/32 gw xxx.xxx.xxx.xxx tun0 #added to route only my nas box through the vpn tunnel

Should I add a link to this script at the end of the vpn client configuration file?
How will I know which ip address to route 192.168.1.3 to (the x's)? Mullvad uses more than one vpn server so that ip address changes...

(Last edited by Nikotine on 4 Apr 2013, 15:36)

Post #19

brontide

4 Apr 2013, 15:41

If you want multiwan to simply setting up rules, you probably want to merge those first two into a "regular" default route. Then you can control traffic with multiwan rules ( in theory ). Yeah, you're probably learning more about routing then you every wanted. If you think this is complex, it only gets worse as you deeper into the rabbit hole.

route add -net 0.0.0.0/0 gw xx.xx.xx.xx tun0

You might want to explore the route-noexec and setup a script to filter. It would handle 3 cases.

0.0.0.0/1 should be replaced with 0.0.0.0/0 ( fixup the default )
128.0.0.0/1 should be ignored ( drop the other /1 )
others should be setup normally

Post #20

Nikotine

4 Apr 2013, 16:02

I'm not sure if I still need multiwan.
What else does it do apart from changing routes, if I don't use the balacing features?

Post #21

brontide

4 Apr 2013, 16:24

Feel free to give it a go, it's non-trivial to redirect some traffic since it needs to be masqueraded with a different source address ( even if it got to the destination because the VPN was not ingress filtered, your traffic would come back wrong and un-vpn'ed ).

Everything I've read seems to indicate you still need the defalut routes, and you need to setup "routing tables" so that you can do "Via" routing.

http://panaharjuna.wordpress.com/2009/1 … -gnulinux/

Post #22

Nikotine

4 Apr 2013, 17:49

Well, if it would help me, I'd sure like to use multiwan, but the problem is that as soon as I enable it, all that happens is that the default route disappears, with or without the vpn running:

root@OpenWrt-Beneden:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br-wan
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan

Post #23

brontide

4 Apr 2013, 18:04

check the debugging section of the multiwan wiki page.

Post #24

Nikotine

5 Apr 2013, 22:59

I've got it working. This is the multiwan config file:

config multiwan 'config'
    option default_route 'wan'
    option enabled '1'

config interface 'wan'
    option timeout '3'
    option health_fail_retries '3'
    option health_recovery_retries '5'
    option weight 'disable'
    option health_interval 'disable'
    option dns '8.8.8.8 8.8.4.4'
    option icmp_hosts 'dns'
    option failover_to 'wan'

config interface 'vpn_interface'
    option timeout '3'
    option health_fail_retries '3'
    option health_recovery_retries '5'
    option weight 'disable'
    option health_interval 'disable'
    option dns '8.8.8.8 8.8.4.4'
    option icmp_hosts 'gateway'
    option failover_to 'vpn_interface'

config mwanfw
    option wanrule 'vpn_interface'
    option src '192.168.1.3/32'

When I do a traceroute from 192.168.1.3, the route goes through the vpn:

nas4free:~# traceroute google.be
traceroute to google.be (173.194.66.94), 64 hops max, 52 byte packets
 1  OpenWrt-Beneden.lan (192.168.1.1)  0.280 ms  0.252 ms  0.269 ms
 2  * 10.8.0.1 (10.8.0.1)  52.786 ms  52.527 ms
 3  46-21-99-17-static.serverhotell.net (46.21.99.17)  52.497 ms  54.870 ms  53.240 ms
 4  vl-11.cr1-fbg.glesys.net (79.99.4.14)  53.719 ms  94.897 ms  105.750 ms
 5  ae1.cr1-bma.glesys.net (46.21.96.131)  61.097 ms  60.397 ms  68.406 ms
 6  sol-ix.net.google.com (193.110.13.102)  59.978 ms  60.305 ms  127.661 ms
 7  216.239.43.122 (216.239.43.122)  60.570 ms  62.715 ms  83.023 ms
 8  209.85.254.153 (209.85.254.153)  79.137 ms  86.180 ms  79.528 ms
 9  216.239.47.11 (216.239.47.11)  93.695 ms  166.618 ms  140.373 ms
10  72.14.238.217 (72.14.238.217)  85.955 ms
    72.14.238.41 (72.14.238.41)  122.978 ms  94.920 ms
11  * * *
12  we-in-f94.1e100.net (173.194.66.94)  89.138 ms  85.122 ms  83.775 ms

From any other pc it uses the normal wan:

C:\Users\Nikotine>tracert google.be

Traceren van de route naar google.be [173.194.66.94]
via maximaal 30 hops:

  1     1 ms     1 ms     1 ms  OpenWrt-Beneden.lan [192.168.1.1]
  2     2 ms     1 ms     1 ms  192.168.0.1
  3    10 ms     9 ms    10 ms  ********.access.telenet.be [***.***.**.*]
  4    11 ms     8 ms    11 ms  dD5E0C041.access.telenet.be [213.224.192.65]
  5    12 ms    13 ms    12 ms  dD5E0FD29.access.telenet.be [213.224.253.41]
  6    14 ms    12 ms    13 ms  tengigabitethernet4-2.ar4.bru1.gblx.net [204.245
.39.25]
  7    24 ms    25 ms    30 ms  74.125.50.33
  8    18 ms    17 ms    17 ms  209.85.254.92
  9    17 ms    26 ms    18 ms  209.85.255.74
 10    24 ms    22 ms    27 ms  209.85.240.158
 11    28 ms    24 ms    23 ms  72.14.236.191
 12     *        *        *     Time-out bij opdracht.
 13    24 ms    23 ms    23 ms  we-in-f94.1e100.net [173.194.66.94]

De trace is voltooid.

I am interpreting this correctly, right?

Now I want to understand how multiwan works :-)
I thought it worked by creating new routing tables.
This is the content of rt_tables:

#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
#
170 LoadBalancer
171 MWAN1
172 MWAN2

Those last three seem to be created by multiwan, but when I check them, my 192.168.1.3 route for example isn't there...

root@OpenWrt-Beneden:~# ip route show table 170
192.168.0.0/24 dev br-wan  proto kernel  scope link  src 192.168.0.100
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1
root@OpenWrt-Beneden:~# ip route show table 171
default via 192.168.0.1 dev br-wan  proto static  src 192.168.0.100
192.168.0.0/24 dev br-wan  proto kernel  scope link  src 192.168.0.100
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1
root@OpenWrt-Beneden:~# ip route show table 172
192.168.0.0/24 dev br-wan  proto kernel  scope link  src 192.168.0.100
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1

So how does it work?

Post #25

Nikotine

6 Apr 2013, 01:40

Also, if I check the interfaces page I see data coming in on both tun0 and wan when I download a torrent. Is this normal?

The discussion might have continued from here.

Page 1 of 1