Jump to content

Fonera+ Replicate traffic on second ethernet port


Recommended Posts

So I just ordered the Fonera+ and am brainstorming a bit. Well I definitely want a BackTrack system to sniff the traffic that goes though the Fon running Jasager. But my question is: Do I have to use 2 network interfaces on my computer to bridge the Fon+ to the internet or is it somehow possible to replicate all of the traffic going through the internet out of the other ethernet port on the Fon?

I recall hearing something about Jasager (Open-Wrt) not using the second ethernet port.

Any other ideas? Maybe a network tap between the internet and Fonera, then I avoid using 2 nics on my PC.

edit: oops an ethernet tap requires 2 nic's aswell I just found out :P.

Link to comment
Share on other sites

  • Replies 62
  • Created
  • Last Reply

Top Posters In This Topic

I'm not clear on the setup you want but if you are passing traffic from the Fon through a laptop and out to the internet, i.e. using ICS then you just sniff the relivant interface on the laptop. If you are plugging the fon directly into a switch then I'd plug something else in between the fon and the switch and then just route traffic through that, again, sniff the bridged network.

The Interceptor would be great for doing something like that.

Link to comment
Share on other sites

  • 4 months later...
I'm not clear on the setup you want but if you are passing traffic from the Fon through a laptop and out to the internet, i.e. using ICS then you just sniff the relivant interface on the laptop. If you are plugging the fon directly into a switch then I'd plug something else in between the fon and the switch and then just route traffic through that, again, sniff the bridged network.

The Interceptor would be great for doing something like that.

I see what he wants, after setting up my Fonera+ it makes sense. The fonera+ has a WAN and a LAN port so the idea is that you hook up the WAN port to the internet and then you hook up your computer to the LAN It's hybrid interceptor and Jasager.

The wifi is serving as the Jasager in this case and the interceptor is mirroring the traffic it sees from WIFI to WAN onto the LAN also. Would be a really neat idea to get going. The you wouldn't need to set up a bridge in your laptop. The jasager could sit there doing it's thing and you could just plug into the LAN to see what's going on and sniff traffic etc. Of course then hamster and ferret wouldn't work since you'd only be able to monitor the traffic.

Link to comment
Share on other sites

Bridge wifi and WAN and then use daemonlogger to clone all traffic over to LAN. Same setup as Interceptor just swap the interfaces around, ath0 becomes eth0.0 and the bridge is on eth0.1 and ath0.

Link to comment
Share on other sites

  • 4 weeks later...

Just to verify

#!/bin/sh /etc/rc.common

start() {
    ifconfig br-lan 0.0.0.0
    brctl addif eth0.1 ath0
    ifconfig eth0.0 10.255.255.254 up
}

stop() {
    echo "Nothing to do"
}

This should bridge WIFI to LAN and The VPN client will also need to be changed to run on the LAN?

Link to comment
Share on other sites

Ok let's see if I understand this:

ASSUMPTION

eth0.0 LAN

eth0.1 WAN

I hope I got that much right.

root@OpenWrt:/interceptor/bin# vi /etc/init.d/interceptor

#!/bin/sh /etc/rc.common

start() {

ifconfig br-lan 0.0.0.0

brctl addif br-lan eth0.1

brctl addif br-lan ath0

ifconfig eth0.0 10.255.255.254 up

}

stop() {

echo "Nothing to do"

}

ifconfig br-lan 0.0.0.0

This sets up the virtual bridge ------------

brctl addif br-lan eth0.1

This bridges the WAN of the Fonera+ to the virtual bridge |__

brctl addif br-lan ath0

This bridges the Wifi of the Fonera+ to the virtual bridge __|

So we have

eth0.1 WAN___|------br-lan------|___WIFI ath0

Then

ifconfig eth0.0 10.255.255.254 up

this assigns the LAN a static IP of 10.255.255.254 so that it can work with OpenVPN and daemonlogger. It's now acting more like the ethernet card in a laptop rather then a router. It's the client not the server.

Now the magic happens

root@OpenWrt:/interceptor/bin# vi startup.sh

#!/usr/bin/env sh

if [[ -f /interceptor/openvpn/client/client1.key && -f /interceptor/openvpn/clie

then

if [[ "$1" != "" ]]

then

/bin/date $1

fi

/usr/sbin/openvpn /interceptor/openvpn/client/client.conf &

/bin/sleep 10

/interceptor/bin/daemonlogger -i br-lan -o tap0 -d

/interceptor/bin/daemonlogger -i br-lan -o tap0 -d

Daemonlogger handles mirroring the bridged traffic (br-lan) out to the OpenVPN tap interface.

If this is all true I understand that the LAN port is now acting like client to our VPN server running on our laptop.

Assuming I got all the above correct, where is the magic that tells the tap0 interface to bind to the LAN eth0.0?

Hopefully, when all is said and done:

Jasager will be running on ath0 to say Yes to everybody and happily route all traffic out to the WAN port and I'll be hooked into the LAN running OPENVPN server for the Lan port to connect to and I'll be able to see all the traffic by sniffing the tap interface on my laptop. The gives me a few things. Only the Jasager traffic will be on the tap interface. If I was bored I can still associate my laptop's wireless to the real AP and surf the internets, etc.

So, if anyone asks "how do you expect the WAN port to get to the internet?". Simple I use my D-link pocket router and set the switch on the bottom to client and plug it's ethernet into the WAN. Yeah it's a kludge but it'll work.

Link to comment
Share on other sites

Daemonlogger will clone from whatever interface you want to the other, the challenge is to get it on to an interface that will accept the traffic. If you read my write up you'll see I did quite a bit of head banging trying to clone wired traffic directly onto the wifi interface and onto the wrong end of a VPN connection. As long as you make the setup with the bridge and the VPN in the right places then it will work but you just have to make sure that you've got it wired up correctly.

Link to comment
Share on other sites

  • 1 month later...

Back to this idea as my first try failed miserably and I got away from it for a bit (busy with Amatuer radio and licensing). Here's the scenarios.

In essence I'd like to do the following as an exercise in futility or splendid ??. This is somewhat a re-hash of what I was trying to accomplish previously but also to get my thought process back on track and open for comment and ideas.

Hardware: Fonera +

Starting Softwaere: Jasager, OpenWrt Kamikaze 8.09, X-wrt

Scenario 1:

Using the Fonera+ install Jasager and get it working - done

Connect laptop to WAN to serve as ICS connection - done

Sniff the ICS traffic - done

Scenario 2:

Connect WAN to network jack in the wall - should work just the same as above however but now I don't have a direct way to monitor traffic going from WLAN to WAN

So, now I would like to be able to do two things:

1. Have DHCP on the LAN port so that I can connect to the Jasager webpage and manage the Jasager

2. Be able sniff on the LAN and see the wireless traffic passing through to the WAN

I don't think I can do both or can I ? From past postings and reading your details it appears that I might be able to do something similar to what you did.

The Plan

Create a VPN client on the FON and attach it to the LAN. Use Daemonlogger to clone traffic from the WAN to the VPN interface. Then have a VPN server on the laptop that is connected to the LAN and sniff the VPN traffic.

My concern is being able to also use the LAN as a normal connection at the same time. I'm not concerned so much with TTL and creating a transparent/passive ethernet tap since this isn't really an interceptor anymore.

Granted If this works I'll end up having to do some manual filtering in my logs of "local" traffic that sneaks out on the WAN. But not a big deal.

If this works as intended I've got to 2 ways to interact with traffic. I could have a laptop on the WAN with ICS doing "stuff" (rogue image injection, etc) and I could also be capturing traffic through the VPN on the LAN.

What I'm afraid of happening is that I completely knock out the LAN port setting this up and then I have to re-flash and start all over. So, I'm not sure what the safest "plan of attack is".

In the end if it all works we'll of course need some kind of hybrid Pirate Monkey Armored Pineapple sticker :)

Link to comment
Share on other sites

The way the Interceptor works it can have the bridge between eth0 and 1 where the bridge has an IP address as well so you can talk to it. So you can do this with the setup you are talking about, I think, and things should work.

Link to comment
Share on other sites

The way the Interceptor works it can have the bridge between eth0 and 1 where the bridge has an IP address as well so you can talk to it. So you can do this with the setup you are talking about, I think, and things should work.

Thanks Robin. After finally getting some time to do some testing I found that I forgotten that the Fon+ is bridged differently then the regular Fon. I was running into all kinds of issues with my Sager with a Realtek wireless and then switched over to a Dell with Atheros wireless and that's when I discovered the Jasager wasn't set up properly. It would connect but never get an IP. I had forgotten about all the uci commands that were needed . So, as it stands now with just the Jasager firmware and the rest of the items on that link, the LAN is part of the wireless. It gets karma bitch slapped when I plug in or connect wirelessly. Alas, it won't be until Sunday until I get some time to test out strategies.

Link to comment
Share on other sites

hi beakmyn!

your concept sounds interessting!

if you got it working could you describe the exact way "how" to accomplish that?

would be really cool as I would love to do the same thing to my jasager ;-).

(its not about making it more easier, but a lot more comfortable in that way - and easy capturing under backtrack ^.~).

greetings,

xeno

Link to comment
Share on other sites

hi beakmyn!

your concept sounds interessting!

if you got it working could you describe the exact way "how" to accomplish that?

would be really cool as I would love to do the same thing to my jasager ;-).

(its not about making it more easier, but a lot more comfortable in that way - and easy capturing under backtrack ^.~).

greetings,

xeno

Once I get it working I'll post details. I got a brief amount of time with it today and it looks like the Lan are wifi are on the same subnet however it looks like they are isolated from each other somehow. That's as far as I got, haven't investigated it yet....

Link to comment
Share on other sites

All the information is located here if you know what pieces of the puzzle belong where:

http://hak5.org/forums/index.php?showtopic=10565

This little tidbit of info is what got it working for me:

http://www.gargoyle-router.com/phpbb/viewt...hp?f=5&t=57

The easiest method.

Step 1

Install Jasager Firmware onto your Fon+ 2201 using Fon Flash <<<<1st puzzle piece (easiest way to get firmware flashed)

http://www.gargoyle-router.com/download.php

Step 2

uci set network.wifi=interface <<<<<<<<<2nd puzzle piece (if you don't issue this command first all others will fail)

Fon+ has 3 interfaces lan, wan wifi – by default wifi interface is not configured

root@OpenWrt:~# uci set network.wifi.ifname=ath0

root@OpenWrt:~# uci set network.wifi.proto=static

root@OpenWrt:~# uci set network.wifi.ipaddr=192.168.1.1

root@OpenWrt:~# uci set network.wifi.netmask=255.255.255.0

root@OpenWrt:~# uci set network.wifi.dns=192.168.1.1

root@OpenWrt:~# uci set dhcp.cfg0875fa=dhcp

root@OpenWrt:~# uci set dhcp.cfg0875fa.start=2

root@OpenWrt:~# uci set dhcp.cfg0875fa.limit=250

root@OpenWrt:~# uci set dhcp.cfg0875fa.leasetime=60m

root@OpenWrt:~# uci set dhcp.cfg0875fa.ignore=0

root@OpenWrt:~# uci set dhcp.cfg0875fa.interface=wifi

root@OpenWrt:~# uci commit

Step 3 <<<<3rd puzzle piece

vi /etc/config/firewall

uncomment the following line

# include a file with users custom iptables rules
config include
        option path /etc/firewall.user

step 4 <<<<Final piece of the puzzle the other firewall rules in the fon 2201 post didn't work for me this did

vi /etc/firewall.user

Add the following lines

The fix was to add a rule to iptables that allows all traffic that originates from the lan and is going back to the lan:

iptables -I zone_lan_forward -i br-lan -o br-lan -j ACCEPT

Now the lan can see the wireless traffic! However the wireless can also see the lan so this is a double-edged sword, beware it's sharp! Also, Jasager will scan the lan connections too!

For me this accomplishes what I wanted which is to sit on the LAN port and interact with Jasager and the wifi clients. So, getting daemonlogger and openvpn to work isn't as important now.

Link to comment
Share on other sites

Now the lan can see the wireless traffic! However the wireless can also see the lan so this is a double-edged sword, beware it's sharp! Also, Jasager will scan the lan connections too!

For me this accomplishes what I wanted which is to sit on the LAN port and interact with Jasager and the wifi clients. So, getting daemonlogger and openvpn to work isn't as important now.

What do you mean by scan the lan connections?

I'm not seeing exactly what you have achieved here beyond being able to ssh to the fon and see traffic which you could do before anyway.

I know I'm missing something, what?

Link to comment
Share on other sites

What do you mean by scan the lan connections?

I'm not seeing exactly what you have achieved here beyond being able to ssh to the fon and see traffic which you could do before anyway.

I know I'm missing something, what?

Disclaimer: I've got a bad head cold and I'm full of cold medicine and beer. Great for battling a cold but not so great for coherent posts.

Granted I didn't accomplish much, yet. Out of the box on the Fon2201 the lan and wifi are isolated from each other, so although they were on the same subnet and had the same DHCP server theere wasn't an iptables rule to allow them to talk to each other. I've put all the pieces to get the lan to see the wifi and vice versa in one post. Now, with that out of the way you can easily sniff traffic albeit everything is on the same connection. I think the next step will be to make the lan compeletly seperate from the wifi via a vlan or similiar and then introduce the interceptor code to mirror the wifi traffic to a tun interface via the lan/openvpn.

Link to comment
Share on other sites

Hello beakmyn,

I tried your idea and set up as described - and the both ports do work in that way:

I connected my real Router to the Wan Port and my Eee to the Lan Port.

I booted the Eee into BT3 and fired up Hamster 2.

Then I surfed the Web over the Wlan Access from an another Pc.

But sadly - I can prove that with Wireshark - I can't see the Traffic of the Wlan surfing Device on the Lan Port...

Any thoughts about it?

Thank you,

Xeno

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

Ok finally had some time to get this up and try to get it running. I'm about 50% there. Right now it's a somewhat manual process.

Note: I have set the wifi interface to start up at boot. Jasager is manually started.

@DigiNinja e.t. al I need some help seeing where I went wrong.

Problems:

1. Before VPN is started I can access FON on 192.168.1.1 (web/ssh)

After VPN is started "Host unreachable" so I can't start Jasager, etc.

2. I do not see the traffic being replicated to tap0

  • First I boot up my backtrack laptop and start eth0. It's manually set for 192.168.1.254 with a gateway of 192.168.1.1 (fon)
  • Now, I plug in my WAN and LAN to the FON and fire it up.
  • Start up Jasager from http://192.168.1.1:1471
  • Connect my victim to Jasager, it's get's an ip and can access the internet through WAN
  • run startup.sh from backtrack laptop

The following should allow the lan to see wifi traffic then daemonlogger handles replicating br-lan to tap0?

root@OpenWrt:/etc/init.d# brctl addif br-lan ath0
root@OpenWrt:/etc/init.d# brctl show
bridge name     bridge id               STP enabled     interfaces
br-lan          8000.001884a278f8       no              ath0
                                                                       eth0.0

Here's the startup.sh from backtrack

root@bt:~# sh startup.sh
Starting vpn server
Mon Jan 18 10:01:49 2010 OpenVPN 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Oct 15 2008
Mon Jan 18 10:01:49 2010 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Mon Jan 18 10:01:49 2010 Diffie-Hellman initialized with 1024 bit key
Giving server chance to start
Mon Jan 18 10:01:49 2010 WARNING: file '/etc/openvpn/interceptor/interceptor.key' is group or others accessible
Mon Jan 18 10:01:49 2010 /usr/bin/openssl-vulnkey -q -b 1024 -m &lt;modulus omitted&gt;
Mon Jan 18 10:01:49 2010 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan 18 10:01:49 2010 TUN/TAP device tap0 opened
Mon Jan 18 10:01:49 2010 TUN/TAP TX queue length set to 100
Mon Jan 18 10:01:49 2010 /sbin/ifconfig tap0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Mon Jan 18 10:01:49 2010 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan 18 10:01:49 2010 GID set to nobody
Mon Jan 18 10:01:49 2010 UID set to nobody
Mon Jan 18 10:01:49 2010 Socket Buffers: R=[110592-&gt;131072] S=[110592-&gt;131072]
Mon Jan 18 10:01:49 2010 UDPv4 link local (bound): [undef]:1194
Mon Jan 18 10:01:49 2010 UDPv4 link remote: [undef]
Mon Jan 18 10:01:49 2010 MULTI: multi_init called, r=256 v=256
Mon Jan 18 10:01:49 2010 IFCONFIG POOL: base=10.8.0.2 size=253
Mon Jan 18 10:01:49 2010 IFCONFIG POOL LIST
Mon Jan 18 10:01:49 2010 client1,10.8.0.2
Mon Jan 18 10:01:49 2010 Initialization Sequence Completed
Starting remote services
root@192.168.1.1's password:
Mon Jan 18 10:01:00 UTC 2010
Mon Jan 18 10:01:02 2010 OpenVPN 2.0.9 mips-linux [SSL] [LZO] built on Feb 17 2009
Mon Jan 18 10:01:02 2010 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Mon Jan 18 10:01:02 2010 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Jan 18 10:01:02 2010 WARNING: file '/interceptor/openvpn/client/client1.key' is group or others accessible
Mon Jan 18 10:01:02 2010 LZO compression initialized
Mon Jan 18 10:01:02 2010 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan 18 10:01:02 2010 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan 18 10:02:12 2010 MULTI: multi_create_instance called
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 Re-using SSL/TLS context
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 LZO compression initialized
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 Local Options hash (VER=V4): 'f7df56b8'
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 Expected Remote Options hash (VER=V4): 'd79ca330'
Mon Jan 18 10:02:12 2010 192.168.1.1:49426 TLS: Initial packet from 192.168.1.1:49426, sid=47cbdf02 0797d88a
Mon Jan 18 10:01:02 2010 Local Options hash (VER=V4): 'd79ca330'
Mon Jan 18 10:01:02 2010 Expected Remote Options hash (VER=V4): 'f7df56b8'
Mon Jan 18 10:01:02 2010 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Mon Jan 18 10:01:02 2010 UDPv4 link local: [undef]
Mon Jan 18 10:01:02 2010 UDPv4 link remote: 192.168.1.254:1194
Mon Jan 18 10:01:02 2010 TLS: Initial packet from 192.168.1.254:1194, sid=edf73771 15139c2e
Mon Jan 18 10:01:02 2010 VERIFY OK: depth=1, /C=US/ST=XX/L=Cyber/O=Interceptor/CN=Interceptor/emailAddress=me@myhost.mydomain
Mon Jan 18 10:01:02 2010 VERIFY OK: depth=0, /C=US/ST=XX/L=Cyber/O=Interceptor/CN=interceptor/emailAddress=me@myhost.mydomain
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 VERIFY OK: depth=1, /C=US/ST=XX/L=Cyber/O=Interceptor/CN=Interceptor/emailAddress=me@myhost.mydomain
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 VERIFY OK: depth=0, /C=US/ST=XX/L=Cyber/O=Interceptor/CN=client1/emailAddress=me@myhost.mydomain
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 18 10:01:03 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 18 10:01:03 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 18 10:01:03 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 18 10:01:03 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jan 18 10:02:13 2010 192.168.1.1:49426 [client1] Peer Connection Initiated with 192.168.1.1:49426
Mon Jan 18 10:01:03 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jan 18 10:01:03 2010 [interceptor] Peer Connection Initiated with 192.168.1.254:1194
Mon Jan 18 10:02:15 2010 client1/192.168.1.1:49426 PUSH: Received control message: 'PUSH_REQUEST'
Mon Jan 18 10:02:15 2010 client1/192.168.1.1:49426 SENT CONTROL [client1]: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)
Mon Jan 18 10:01:04 2010 SENT CONTROL [interceptor]: 'PUSH_REQUEST' (status=1)
Mon Jan 18 10:01:04 2010 PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0'
Mon Jan 18 10:01:04 2010 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jan 18 10:01:04 2010 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jan 18 10:01:04 2010 OPTIONS IMPORT: route options modified
Mon Jan 18 10:01:04 2010 TUN/TAP device tap0 opened
Mon Jan 18 10:01:04 2010 /sbin/ifconfig tap0 10.8.0.2 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Mon Jan 18 10:01:04 2010 GID set to nogroup
Mon Jan 18 10:01:04 2010 UID set to nobody
Mon Jan 18 10:01:04 2010 Initialization Sequence Completed
[-] Daemon mode set
[-] Interface set to br-lan
[-] Log filename set to "daemonlogger.pcap"
[-] Tap output interface set to tap0[-] Pidfile configured to "daemonlogger.pid"
[-] Pidpath configured to "/var/run"
[-] Rollover size set to 2147483648 bytes
[-] Rollover time configured for 0 seconds
[-] Pruning behavior set to oldest IN DIRECTORY

-*&gt; DaemonLogger &lt;*-
Version 1.2.1
By Martin Roesch
(C) Copyright 2006-2007 Sourcefire Inc., All rights reserved

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...