4

I have been trying to find information on this and perhaps I don't know what I am looking for. Everything I find is about simulating poor performance to test an application; that is not what I am after.

I have built a lab to practice and teach IT Security techniques. The lab is entirely internal with no real internet connectivity (unless I need it to update something then I just switch interfaces).

I am wanting to have one VM inside this lab have a 'public' IP. Let's say 137.74.131[.]208 for an example. I want to have this VM attack other devices in my lab so that the firewall, SIEM, etc sees it as an external IP and not another private IP.

My current setup is running inside ProxMox with quite a few things joined by a single PfSense. I.e.

PfSense with LAN (10.10.10.x IP) and WAN (192.168.1.x IP) interfaces on vmbr1 and vmbr0 interfaces respectively Kali-linux (assigned to vmbr0 interface) IIS servers (assigned to vmbr1 interface, port forwarding through pfsense) workstations, domain controllers, siem, etc etc (assigned to vmrb1 interface) In my current setup I have some nice automated attacks from the kali box, great alerting, and an all around great place to learn and teach IR and Blue team stuff. But everything malicious shows up as coming from 192.168.1.x.

I have seen labs where they have simulated external IPs on their network but I have no idea how they've done this. Any advice would be greatly appreciated.

1 Answer 1

7

The simplest way is… to literally just assign the addresses to your "WAN" interfaces in exactly the same way as you've currently assigned the 192.168.1.x.

Decide on whatever subnet size you prefer (let's say /24), then assign 137.74.131.208/24 to the Kali VM and another address from the same subnet (for example 137.74.131.204) to the pfSense WAN interface.


The reason you're not finding any information is because there is nothing to simulate. On the technical level, there is no difference between "public" and "private" IP addresses – they both are configured in the same way, routed in the same way, subnetted in the same way, and so on.

The only difference is just policy: real-world RIRs will refuse to issue private addresses, real-world ISPs will refuse to accept private routes on the public Internet. But since you're on an isolated network you can do anything you wish, and that includes just straight up configuring any address on any VM.

8
  • Thank you much! I was thinking of doing something similar to that. Let's say I wanted my target network to have an ip in a completely different subnet than the attacker. Works I need to setup 2 pfsense for both ends? Would they be able to talk to each other?
    – JohnD
    Commented Aug 15, 2020 at 14:55
  • 1
    Yes, set up a second router (pfSense or something else), configure routes from one router via another, and configure routes in the opposite direction as well. That's basically how the actual Internet works. Commented Aug 15, 2020 at 15:27
  • 1
    If both WAN interfaces are facing each other then they need to be in the same subnet. If you want Kali to use e.g. 48.132.230.134, you can use this range for the new pfsense LAN. Just don't forget to turn off pfsense NAT. But if you want the new pfsense itself to have a WAN address like this, then you'll need a third router in between – which again will have the 137.x on one side, 48.x on another. Commented Aug 17, 2020 at 4:11
  • 1
    (To be honest I don't really like using pfsense in this situation – sure it'll do the job, but its default NAT is unneeded and its insistence on "WAN" and "LAN" names is completely irrelevant and probably confuses things a lot. Would probably recommend your simulated internet to be built of something more generic, like barebones Linux or BSD or RouterOS, and only keep that one pfSense you had in the beginning.) Commented Aug 17, 2020 at 4:18
  • 1
    Well, I wasn't necessarily suggesting a "more router like" OS but instead a "less home-gateway like" OS. (For example, Debian Linux isn't a router OS at all, but I still think it's more suitable for simulating a WAN than pfSense, precisely because it wasn't built around the 'NAT gateway' assumptions.) Commented Aug 19, 2020 at 6:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .